It's Time to Move to RBAC for Key Vault

Azure Key Vault has had a strange quirk since its release. Access to the keys, secrets, and certificates in the Vault was not governed by Azure RBAC permissions but by a completely separate access control system through Key Vault Access Policies. Access Policies uses a different UI, separate resource types and didn’t support standard RBAC features such as custom roles.

Microsoft has been working on implementing proper RBAC access for Key Vault for a while now, and this feature is now ready to use and out of preview status, and it’s time to start migrating to using RBAC rather than access policies.

Benefits

Moving to Azure RBAC offers several benefits over access policies:

• Aligning access controls with the rest of Azure’s RBAC system
• Support for custom roles
• Support for secret/key level permissions - using RBAC, you can create a custom role that only has permission to a specific secret. With access policies, you can only grant access to all secrets
• Supports the use of Privileged Identity Management for Just In Time access

There are a couple of things to be aware of, however:

• Assignment delay - RBAC permissions can take a few minutes to apply after you add them, unlike access policies which were nearly instant
• Role Assignment Limit - there is a limit of 2000 role assignments per subscription, whereas access policies had a limit of 1024 per Key Vault (no subscription)

Migrating to RBAC Permissions

To migrate to RBAC, you need to switch the Vault into RBAC mode. You cannot have both Access Policies and RBAC active at the same time. However, before you do this, you will want to create and assign the appropriate roles to your users to avoid losing access to the Vault.

Roles

The first thing to understand is whether the built-in Key Vault roles are good enough for what you need or if you need to create some custom roles. There are seven built-in roles:

• Key Vault Administrator - full access to all resources
• Key Vault Reader - read metadata of Vault and resources, cannot access values of resources in Key Vault
• Key Vault Certificate Officer - perform any action on certificates except changing permissions
• Key Vault Crypto Officer - perform any action on keys except changing permissions
• Key Vault Crypto User - perform cryptographic operations with keys in the Key Vault
• Key Vault Crypto Service Encryption User - read metadata of keys and perform wrap/unwrap operations
• Key Vault Secrets Officer - perform any action on secrets except changing permissions
• Key Vault Secrets User - read the contents of secrets

If none of the roles above does what you need, you can create an Azure custom role with the specific rights you need. I discuss how to create custom roles in detail here. The vital thing to be aware of with Key Vault is that the permissions you need to access resources in a Key Vault are all in the “DataActions” section. For example, the role below allows users to read and update secrets but not delete them.

{
  "Name": "Secret Management",
  "Description": "Read and Update Secrets",
  "Actions": [],
  "DataActions": [
    "Microsoft.KeyVault/vaults/secrets/read",
    "Microsoft.KeyVault/vaults/secrets/write"
  ],
  "NotDataActions": [],
  "AssignableScopes": ["/subscriptions/{subscriptionId}"]
}

You can also use the “NotDataActions” section to exclude specific permissions.

Depending on your requirements, the built-in and custom roles can be applied at the Vault or individual item scope. We will see more on how to do this shortly.

Assign Permissions

Now you have the required roles for your users to access Key Vault, you need to assign them to the Vault. Ideally, you want to do this before switching to RBAC permissions for Key Vault to avoid people losing access. However, it is only possible to do this if your permissions are applied at the vault level. Using permissions at the secret/key/certificate level doesn’t get enabled until you switch to RBAC permissions.

Assigning permissions at the vault level is the same as any other Azure resource. In the portal, go to the Vault, then the “Access Control IAM” tab and assign the required role. You can also apply these at the resource group, subscription or management group level if you want to grant permissions on multiple vaults.

One other thing to be aware of with Key Vault permissions is that someone who is an owner or contributor on the subscription or resource group does not grant permissions to read data in Key Vault. These users still need to expressly be granted a Key Vault data role in addition to their other rights.

Switch to RBAC Permissions

Now you have your roles and assignments set up, it is time to switch to RBAC. To do this, go to the “Access Policies” tab, where you will see a radio button to select which permission method you use.

Click on “Azure role-based access control”, and you will be presented with a warning. When you switch, any existing access policy permissions will immediately cease working. You need to make sure that you have assigned all the RBAC permissions you need, or you have a maintenance window in place to allow you some time to set them up when you turn this on.

Assuming you are happy with this, go ahead and click the “save” button. Once this operation completes, you have successfully switched to RBAC mode.

Assign Resource Level Permissions

As mentioned before, you cannot assign rights to specific secrets/keys/certificates until you switch to RBAC mode. Once you have changed, you can go to a particular resource, and you should now see an “Access Controls” section. You can apply any roles (built-in or custom) at this level now.

One thing I would say about this is to use these resource-level permissions sparingly. If you have different permissions for every secret or key, you will have to manage and update this complex set of permissions. If you find yourself doing a lot of this, it may be worth considering if you would be better off splitting your resource over multiple Key Vaults instead and scoping these to a more narrow purpose.

Conclusion

Using RBAC permissions for Key Vault is a much better experience than using access policies. It does away with the weird separate permissions system unique to Key Vault, brings it in line with the rest of Azure, and provides new features. I would recommend that any new Key Vaults you create use RBAC roles and migrate existing ones when you can.