Azure Key Vault permission

Question

I'm facing an Azure Key Vault permission issue and would appreciate your advice.

Here's the scenario:

• User A has the Contributor role assigned at the Subscription level.
• User B has the Contributor role assigned at the Resource Group level where the Azure Key Vault resides.

However:

• User A cannot generate (create) a secret in the Azure Key Vault.
• User B can generate (create) a secret without any issues.

I'm confused about why the behavior is different, even though User A has Contributor permissions at a higher scope.

Could anyone explain:

• Why is there a difference in behavior between these two users?
• Is this related to Azure RBAC vs. Key Vault Access Policies?
• Are there any additional permissions or roles required to create secrets in Azure Key Vault?
• What is the recommended way to configure permissions so both users can perform the same action?

Any insights or best practices would be greatly appreciated.

Thank you!Hi everyone,

I'm facing an Azure Key Vault permission issue and would appreciate your advice.

Here's the scenario:

• User A has the Contributor role assigned at the Subscription level.
• User B has the Contributor role assigned at the Resource Group level where the Azure Key Vault resides.

However:

• User A cannot generate (create) a secret in the Azure Key Vault.
• User B can generate (create) a secret without any issues.

I'm confused about why the behavior is different, even though User A has Contributor permissions at a higher scope.

Could anyone explain:

• Why is there a difference in behavior between these two users?
• Are there any additional permissions or roles required to create secrets in Azure Key Vault?
• What is the recommended way to configure permissions so both users can perform the same action?

Any insights or best practices would be greatly appreciated.

Thank you!

Answer 1

The difference is caused by the Key Vault permission model in use and by the fact that Contributor is not a data-plane secret management role.

If the vault uses Azure RBAC:

• Creating a secret requires a Key Vault data-plane role such as Key Vault Secrets Officer.
• A subscription Owner or Contributor role does not by itself grant permission to write secrets.
• To assign Key Vault roles, the assigner must have Microsoft.Authorization/roleAssignments/write, such as Key Vault Data Access Administrator, User Access Administrator, or Owner.

If the vault uses the legacy access policy model:

• Access to secrets is controlled by Key Vault access policies, not by Azure RBAC data-plane roles.
• Users with Contributor, Key Vault Contributor, or any role including Microsoft.KeyVault/vaults/write can grant themselves data-plane access by configuring a Key Vault access policy. This is why the access policy model is considered less secure.
• In troubleshooting guidance, inability to list/get/create secrets is resolved by ensuring the correct Azure RBAC role is assigned, or by using the legacy access policy model correctly if that model is enabled.

Why User B can create secrets while User A cannot:

• If the vault is using access policies, User B may be able to modify the vault configuration at the resource group scope and add or benefit from an access policy that allows secret creation.
• If the vault is using Azure RBAC, User B likely has an explicit Key Vault data-plane role on the vault or inherited at a relevant scope, while User A does not.
• Higher scope Contributor does not guarantee secret creation rights because secret creation is a data-plane operation, and control-plane roles do not automatically provide that access.

Recommended configuration:

1. Prefer Azure RBAC over access policies for improved security.
2. Assign a Key Vault data-plane role such as Key Vault Secrets Officer to both users at the Key Vault scope.
3. Use role assignments at the vault scope rather than on individual secrets, except for limited exception scenarios.
4. Avoid relying on Contributor for secret access.

Portal path for the recommended setup:

1. Open the Key Vault.
2. Go to Access control (IAM).
3. Select Add > Add role assignment.
4. Assign Key Vault Secrets Officer to each user.

Example Azure CLI role assignment at vault scope:

az role assignment create --role "Key Vault Secrets Officer" --assignee <user-principal-name> --scope /subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>

Important:

• Switching a vault to Azure RBAC invalidates all existing access policy permissions and can cause outages if equivalent Azure roles are not assigned first.
• Assigning roles on individual secrets, keys, or certificates is generally not recommended except for limited scenarios.

---

References:

• Provide access to Key Vault keys, certificates, and secrets with Azure role-based access control
• Troubleshooting Azure Key Vault access policy issues
• Azure role-based access control (Azure RBAC) vs. access policies (legacy)
• Quickstart: Set and retrieve a secret from Azure Key Vault using PowerShell
• Azure built-in roles for Security