TL;DR: You can configure individual RBAC on keys, secrets, and certificates in Azure Key Vault with RBAC enabled.

Role-Based Access Control has been around for Azure Key Vault a while now, and I have used it for a few deployments. The option for individual Access Control escaped my attention, though. There’s always an opportunity to learn something new in the fast and ever moving cloud.

The reason I just recently stumbled upon this functionality, is the extra step when accessing Key Vault secrets:

Notice the Access control option (IAM) option. It made me wonder, and I needed to test it.

Testing it

Key Vaults cost next to nothing, so you can easily test how this works in your own subscription:

1. Create a dedicated resource group.
2. Create an Azure Key Vault with RBAC enabled.
3. Create two test secrets: “private” and “public”.
4. Create a test user in your Azure AD.
5. Grant test user the Reader role on subscription scope (just to be sure).
6. Grant test user the role Key Vault Reader at Key Vault Scope. Note that this permission does not grant access to read items, only list them.
7. Grant test user the role Key Vault Secrets Officer at the “public” secret scope.
8. Log in incognito mode with the user you just granted access.
9. Verify read access on the Key Vault by listing all secrets.
10. Verify your permission to read, edit, and delete the “public” secret.
11. Verify your missing permissions on the “private” secret (only list should be allowed).

When following the guide you should be able to verify almost full access on the “public” secret, and no permission on the “private” secret. This proves  you can grant individual access on different secrets in the same Key Vault.

Always delete unnecessary resources after testing is done. It is best not to leave clutter in your subscriptions, both because of cost and consistency.

Use cases

This can open the door for many use cases, but a couple comes to mind.

Apps vault consolidation

Picture 10 different apps requiring secrets storage.

With Access Policy this is a pain to manage, and to get isolation you need 10 different Key Vaults.

With RBAC, you can grant Key Vault Reader to all 10 apps identities on the same Key Vault. They would only be able to list all secrets without seeing the secret value. Then you can grant Key Vault Secrets User to individual apps on the secrets each app needs access to. If one of the identities are compromised, it does not have access to all secrets in the Key Vault!

Separation of duties in single vault

Picture 10 different people working in an IT department, with different access levels. Some manage networks, some are developers and need access to app passwords, some need access to VM login credentials.

With Access Policy you would need to logically separate all secrets in different Key Vaults with different policies.

With RBAC you could keep all secrets in one Key Vault, and grant only access to the secrets for each user/group that needs it. Of course this is not always a practical approach, but at least it is possible.

Environment-wide Key Vault access

This is not specifically because of individual secrets permissions, but rather a possibility because of RBAC on Key Vaults.

Grant Key Vault Administrator at Root Management Group scope to a specific group. Any members will automatically get access to all Key Vaults in the respective Management Group. Furthermore, this is inherited to all child Management Groups, and all child subscriptions. The role only grants access on Key Vaults, in addition to some insights and support.

In summary

Other arguments for logical separation of Key Vaults are still valid, and I am not saying you should put all your eggs in the proverbial single basket, but it could be possible.

Individual permissions seem to also apply on certificates and keys. I have not tested this, but I assume the functionality is equivalent.

Am I just late to the party on this? I think it may have been possible for several months, because of the date on the docs article.

I need to moderate my statements on Key Vault possibilities going forward. Hopefully this reaches someone else that did not realize the possibilities here.