In my use of Azure Key Vault with code and flows with Managed Identities, I moved to role-based access control (RBAC) to manage access to secrets and certificates. However, I encountered a problem when using the “Key Vault Reader” role as it denied me the required access to secret content. This experience highlighted the importance of understanding the specific roles within Azure Key Vault, and I want to share this insight to help others avoid similar pitfalls.

When setting up your managed identity, assigning the “Key Vault Reader” role might seem sufficient, but it will only allow your identity to view the metadata, not the actual secret values. This can lead to confusion and errors, especially if you’re expecting your application to retrieve and use these secrets. See the details here.

The Key Vault Reader Role

The “Key Vault Reader” role might initially suggest that it provides access to the keys, secrets and certificates stored within the Key Vault: it´s called “Reader”…. However, this is a common misconception.

The “Key Vault Reader” role only allows users to view the metadata of the key vault and its objects, not the actual contents of the secrets.
So, this role does not grant access to the actual contents of the secrets.
To access the secret values, it is essential to assign the “Key Vault Secrets User” role, which grants the necessary permissions to read and utilize the secrets.
This role is useful for scenarios where you need to list or view the properties of the key vault objects without accessing their sensitive data.

The Key Vault Secrets User Role

This role grants permissions to read secret contents, which is essential for applications or services that need to retrieve and use these secrets.

The “Key Vault Secrets User” role is designed specifically for accessing the contents of secrets.
Without this role, your managed identity won’t be able to access and read the secret values (leading to issues in your applications).

The Key Vault Secrets Officer Role

This role grants permissions to manage (create, update, and delete) secrets and their contents, which is essential for users or services that need to manage these secrets.

The “Key Vault Secrets Officer” role is designed for managing secrets.
Use this RBAC role for users to access and modify secrets in the key vault.

How to Assign the Correct Role

To avoid this issue, ensure you assign the “Key Vault Secrets User” role to your managed identity. You can do this in the Azure portal, with CLI, and ARM. Here’s a quick guide on how to do this using Azure CLI:

# Sign-in
az login
# Set the current subscription
az account set --subscription "<subscription-id>"
# Assign the Key Vault Secrets User role to a managed identity
az role assignment create --role "Key Vault Secrets User" --assignee <managed-identity-id> --scope <key-vault-resource-id>

Replace <subscription-id>, <managed-identity-id> with your managed identity’s ID and <key-vault-resource-id> with your key vault’s resource ID. You can find the ResourceId in the Key Vault´s Properties. It is a long key that looks like this: “/subscriptions/<subscription-id>/resourceGroups/<resource-group-id>/providers/Microsoft.KeyVault/vaults/<key-vault-name>”. You get back an object with the Id and other metadata. See more at Assign Azure roles using Azure CLI

Automate Deployment

When assigning a role in a Bicep script, we can add the role with the Id of the (built-in) role which is “4633458b-17de-408a-b874-0445c86b69e6” for “Key Vault Secrets User ”.

…
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(keyVault.id, Userid, 'KeyVaultSecretsUser')
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '4633458b-17de-408a-b874-0445c86b69e6') 
    principalId: Userid
    principalType: 'ServicePrincipal'
  }
}
…

You can find the “Key Vault Secrets User” Id (and the other roles) at Azure built-in roles for Key Vault data plane operations.

After the deployment, in this sample, the User Managed Identity “UAM…” has the “Key Vault Secrets User” role assigned in the Key Vault, as here.

This permission allows access for Azure applications to the objects stored in here.

Although individual permissions can be assigned to objects in the Key Vault, this is usually not useful in practice. For simple administration, it is better to assign the permissions to resource groups or to the Key Vault.

Conclusion

Understanding the differences between these roles and assigning the correct one is crucial for the smooth operation of your applications. By using the “Key Vault Secrets User” role, you ensure that your managed identity has the necessary permissions to access and use the secrets stored in Azure Key Vault. The “Key Vault Secrets Officer” role should be assigned to a user or app to be able to create, update and delete secrets. For more detailed information, you can refer to the official Azure Key Vault RBAC guide.