Implement RBAC on Azure Key Vault
Tags: azure, security, cloud, serverless
Published: 2021-02-22 09:10:54

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.

![7.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1613579370000/3oXTcLqpG.png)

## 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](https://docs.microsoft.com/en-us/azure/key-vault/general/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](https://docs.microsoft.com/en-us/azure/role-based-access-control/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](https://docs.microsoft.com/en-us/azure/key-vault/general/rbac-guide)_

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.

![8.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1613579380866/YwUT98ytr.png)

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.

![9.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1613579389487/GXqLLQrB9.png)

## 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.