TL;DR
If you just need a refresher or really need to know how to do this fast, here it is for secrets.
- Assign the identity that needs to read one or more secrets the Key Vault Reader role at the scope of the Key Vault.
- Assign that same identity Key Vault Secrets Officer at the scope of the secret(s) you want it to be able to retrieve the value of.
⚠️ Warning
The identity you grant these permissions to will be able to see all the secrets in the Key Vault
you grant them access to, but it will only be able to read the value of secrets that have the
Key Vault Secrets Officer role assigned to that identity.
Why RBAC for Key Vault Instead of Access Policies?
Traditionally controls in Azure Key Vaults were applied using access policies. The problem with these was that the permissions we granted applied to all objects of that type within a given Key Vault.
For example, if we granted an identity List and Get permissions on secrets in a given Key Vault,
that identity could list all of the secrets in that Key Vault and read the value of all those secrets.
There was no way to limit the scope of an identity to read only some, not all, secrets. The same applies
to keys and certificates.
RBAC for Key Vault gives us the benefit of these more fine-grained controls along with a few added benefits such as support for Privileged Identity Management (PIM) and custom roles. It also brings Key Vault access control in line with the RBAC implementation in place across Azure more broadly.
ℹ️ Tip
An Azure subscription supports 4,000 role assignments, whereas access policies support up
to 1,024 policies per Key Vault. Something to keep in mind when using RBAC for Key Vault at a
large scale.
How to Set up RBAC for Key Vault
The first thing we’ll need to do is either create a new Key Vault or change an existing one to use RBAC for Key Vault instead of access policies. Note that RBAC for Key Vault and access policies cannot co-exist, we have to pick one or the other.
To change an existing Key Vault to use RBAC instead of access policies open the Key Vault in the Azure portal and open up Access configuration and change the selection from Vault access policy to Azure role-based access control then click the Apply button.
⚠️ Warning
Make sure you have the necessary role assignments in place before switching to from access policies
to RBAC or things will lose access to your Key Vault. There's a big warning about this on the
page when you go to make the change as well.
If setting up a new Key Vault we just need to make sure we choose Allow role-based access control
at the access policy stage of the wizard. If using the Azure CLI set the--enable-rbac-authorization flag to true.
Granting Access with RBAC for Key Vault
We’re going to focus on using the built-in roles in this post, but if those aren’t suitable for your needs you can always create a custom role with only the actions you need and apply it in the same way.
There are several built-in roles for working with RBAC for Azure but we’ll be working with the Key Vault Reader and Key Vault Secrets Officer roles. They’re highlighted in the list below.
The Key Vault Reader role is described in the portal as:
“Read metadata of key vaults and its certificates, keys, and secrets. Cannot read sensitive values
such as secret contents or key material.”
And the Key Vault Secrets Officer as:
“Perform any action on the secrets of a key vault, except maange permissions.”
You can find the detailed permissions each role grants in the Azure Portal or using PowerShell or the Azure CLI. More on how to do that can be found here.
The first step is to apply the Key Vault Reader for our identity at the scope of the Key Vault. This will grant the identity we’re assigning the role to the ability to see the Key Vault if they can’t already, as well as all the secrets within the Key Vault. They won’t be able to read or copy the actual values of the secrets, but they will be able to see what secrets exist in the entire Key Vault. If this is going to be a problem in your case you’ll need to set up a separate Key Vault or look into custom roles.
With that in place we can now apply the Key Vault Secrets Officer for our identity at the scope of each secret we want that identity to be able to read the value of. To apply the role at the scope of a given secret, open that secret up in the Azure portal and on the left-hand side there will be an Access control (IAM) menu item, the same as there would be for the Key Vault itself and other Azure resource. You can then apply the Key Vault Secrets Officer role at the scope of the secret (which the portal will refer to as “this resource” in this context) in the exact same way you would apply roles in any other part of Azure.
You can also do this with the Azure CLI like so:
az role assignment create --role "Key Vault Secrets Officer" --assignee user@domain.com --scope /subscriptions/<subscription id>/resourcegroups/<resource group name>/providers/Microsoft.KeyVault/vaults/<key vault name>/secrets/<secret name>
Our identity can now only use the secrets that we have granted it access to with the Key Vault Secrets Officer role. It can see the other secrets exist, but cannot read the value of those secrets.