Azure Key Vault access policies have been a place of confusion when it comes to assigning user and/or group permissions. A desire to introduce an improved method to manage access has been high in demand within the Azure community, until now… Microsoft has announced general availability of Role-Based Access Control (RBAC) to manage permissions within Azure Key Vault, unifying their approach when it comes to access control.
What new roles are there?
The team at Microsoft had to introduce new roles for different permission requirements. They are
- Key Vault Administrator
- Key Vault Certificates Officer
- Key Vault Crypto Officer
- Key Vault Crypto Service Encryption User
- Key Vault Crypto User
- Key Vault Reader
- Key Vault Secrets Officer
- Key Vault Secrets User
The new roles represent access policy templates that already exist. Microsoft have provided an article on mapping these pre-defined policies to the new role - Microsoft Article: RBAC Migration
What about custom permissions?
You can create custom RBAC roles to reflect your access policies custom permissions. To do this, you will need to create a new role within RBAC using either Azure Portal, PowerShell, CLI, or any other IAC methods - Microsoft Article: Custom Roles
Remember to give your custom roles an identifiable name using a naming convention
Getting started
If you are looking to move to this new method of access control within Azure Key Vault, then you need to check out Microsoft’s recommendation on migrating - Microsoft Article: Key Vault RBAC
Read through the options and plan out how you would test the new permissions
How did I do it
Using an existing Key Vault, I initially setup the users, groups and service principals within the IAM blade of my Azure Key Vault. Setting this up first doesn’t implement the permissions as RBAC is yet enabled and the roles specifically state they only work with RBAC.
Once I confirmed the users are mapped to the roles that reflect my current policy setup, I enabled Azure role-based access control by selecting the radio button within the Access policies blade (don’t forget to hit the Save option). I allowed five minutes to pass before testing my access and then test other users/services access.
Word of caution
When setting up these roles, make sure you set the scope correctly. If you are configuring the permissions to a specific Key Vault, then make sure you set the role within the resource itself. If you set the roles at resource group scope for example, any Key Vaults within the resource group will have the same access control permissions.
Plan before you make any changes and if you are going to go ahead with implementing this change to a production Key Vault, then schedule a maintenance window.
Top comments (0)