Part 1: Understanding access to Azure Key Vault Secrets with role-based access control (RBAC)
Azure Key Vault offers a secure way to share secrets with authorized users. For many years, access to Azure Key Vault secrets is secured with vault access policy. A user can be assigned to a vault access policy to add, list, edit, delete secrets (and more), and this means the assigned permission(s) would apply to all secrets and not on an individual secret basis. A further issue with this permission model is that if a user is assigned the Contributor role, then the user would be able to manage vault access policy related to the Azure Key Vault instance and this really negates any policy you have defined as it can be changed by the user.
With Azure Key Vault RBAC, users with role assignment privileges such as Administrator can assign roles. There are two levels of assignments, one on the Azure Key Vault resource level, and one on the secrets level, with each secret having the ability to be assigned access separately. This significantly improves security as we can be very precise in granting the right access to the right users.
When considering RBAC, we would naturally want to take a deeper look at Key Vault specific roles, specifically, the ones related to secrets data plane. As of the time if this writing, we have several, but the ones that I would like to highlight are the Key Vault Reader and Key Vault Secrets User roles. For more information, here’s a link to the docs on the rest of the roles.
As a first step, we will need to be able to “list” secrets. According to documentation for the Key Vault Reader role, this role will allow assigned users the ability to “Read metadata of key vaults and its certificates, keys, and secrets”. As alluded earlier, we are able to assign this role to an individual secret. However, we are unable to “list” this individual secret. In other words, granting this role to a secret does nothing. When assigned on the Azure Key Vault resource level, it does allow me to list all secrets as expected. This means that all users who have access to at least one secret may need to be assigned this role. I will have more on this in the later, but for now, let’s take a look at an example below.
In this example, “Eric Demo” is assigned access to dleekv Azure key Vault with the Key Vault Reader role.
When viewing key vault list, Eric is now able to view his assigned key vault.
When attempting to view a secret, he gets the following error, which brings us to our next step of being able to view secrets.
We should only be able to view the secret(s) we are authorized. According to the documentation for the Key Vault Secrets User role, this role will allow assigned users the ability to “Read secret contents”. Once again, I performed a test by assigning this role to an individual secret. This time, I am able to view said secret, but not on other secrets where I am not assigned this role. This means I will be able to fulfill a key requirement where only authorized users will be able to view assigned secret(s).
So this does pose another interesting question. What will happen if a user is assigned the Key Vault Secrets User role but not assigned the Key Vault Reader role. Will the user still be able to access the secret? Here, it is not possible to experiment with Azure Key Vault on the Azure Portal given the Azure Key Vault wouldn’t even show up in the first place if the user is not assigned the Key Vault Reader role. To test this scenario (and for the fun of it), I created a project on github which uses the REST API of Azure Key Vault. Once configured, the project will list all secrets provided you are assigned the Key Vault Reader role. However, you can actually still access a secret directly provided you know the name of the secret with the following API.
https://<Host name>/secrets/value?id=https://dleekv.vault.azure.net/secrets/app1secret1.
Internally, it makes a REST call to Azure Key Vault API with a bearer token acquired via Microsoft Identity nuget packages. The result of this experiment proves that I am able to access the “app1secret1” secret without the Key Vault Reader role on the Azure Key Vault instance as long as I am assigned the Key Vault Secrets User role on the secret.
Alternatively, we can also demonstrate this behavior by leveraging the Azure CLI command. For more information on this command, see Quickstart — Set and retrieve a secret from Azure Key Vault | Microsoft Docs.
We should understand that if you intend to leverage Azure Key Vault from the Azure portal, you will probably be required to assign the user the Key Vault Reader role which may not be feasible depending on your security requirements. Another approach may be to leverage the Azure CLI, provided you provide the secret name to the assigned user. Alternatively, you can consider creating a project, such as my open source project shown earlier and expose secrets that way, something like a internal password manager application secured by Azure Active Directory and RBAC.
Now that we understand the behaviors related to the two roles, we will want to understand how we can manage secrets operationally which will be part two of this two part series. I do hope you have enjoyed this reading and learned something new today.
