A lot of Azure services have different methods of granting access to users. Storage and Service Bus have access keys (though SB allows you to create them with different accesses), SQL DB has its users, and Key Vault has Access policies. This can be a bit annoying as you need to always find out how every service does authorization.
Now recently services have been moving to support Azure AD authentication combined with using Azure RBAC (Role-Based Access Control). Storage and Service Bus are good examples of this as they allow you to specify per-user/per-app access with quite small granularity. For example, you can define that this group of users can read blobs in this one container in Storage. Or that this one application can receive messages from this queue.
The granularity is not the only advantage of using Azure RBAC. It allows administrators to see what the users/applications can access very easily in a single view. The access is always assigned to a specific user/group/application and the calling user/application can be identified and logged by the service. With access keys etc., you can't really verify the actual user/application that did the operation.
Another advantage of Azure RBAC is that the roles can be assigned at different levels. Access can be granted at the subscription level for example, removing the need of assigning access individually per resource. The granularity is up to you :)
Key Vault now finally also supports Azure RBAC (documentation). Let's go through what has been added.
Turning on Azure RBAC
To use RBAC roles to manage access, you must switch the Key Vault to use Azure RBAC instead of access policies. So no, you cannot use both at the same time. Once you make the switch, access policies will no longer apply. What you can do is assign the necessary roles first to the users/applications that need them, and then switch to use RBAC roles. Do note that currently there is a possible delay:
Role assignments latency: at current expected performance, it will take up to 10 minutes (600 seconds) after role assignments is changed for role to be applied
So it is probably a good idea to assign the roles, wait at least 10 minutes, and then switch over to use RBAC.
To switch a Key Vault to use Azure RBAC, you need to change the Permission model on the Access policies tab to Azure role-based access control.
The best part is that no changes are required in the application side. Since Key Vault always used Azure AD authentication, that will continue to work as before. All the changes are internal to Key Vault and how it authorizes the requests.
New built-in roles
There are 8 new RBAC roles that allow different levels of management in Key Vault:
- Key Vault Administrator
- Any action on all data
- Key Vault Reader
- Read Key Vaults and read metadata (not contents of secrets etc.)
- Key Vault Certificates Officer
- Any action on certificates
- Key Vault Crypto Officer
- Any action on keys
- Key Vault Crypto User
- Read and backup keys + all cryptographic operations with keys
- Key Vault Crypto Service Encryption
- Use keys to wrap/unwrap data
- Key Vault Secrets Officer
- Any Action on secrets
- Key Vault Secrets User
- Read secret contents
You can check more details about the roles in the documentation.
Three of the new roles stand out for me as an application developer: Key Vault Crypto Service Encryption, Key Vault Crypto User, and Key Vault Secrets User.
If your application needs to access secrets, you can give it the Key Vault Secrets User role. If it needs to use ASP.NET Core Data Protection with Key Vault keys, it can use the Key Vault Crypto Service Encryption role. If more access to operations is needed for keys (e.g. data signing), the Key Vault Crypto User role can be used.
Those three roles alone cover a lot of scenarios that applications face typically. The other roles are mostly ones that can be used with users to allow them to manage different parts of the Key Vault data.
If these roles don't satisfy your needs, you can always make custom roles that include some selection of the actions granted to these roles.
Summary
For new Key Vault deployments, I definitely recommend using Azure RBAC to get more uniform access management across Azure services, and to also give administrators more visibility to users' and applications' accesses.
If you are using access policies currently with Key Vault, you are not in a hurry to switch to Azure RBAC. Access policies continue to work and can totally be used. But if those advantages given by Azure RBAC are tempting, you can switch to use it with quite minimal effort.