Owner Role on an RBAC Key Vault Still Returns Forbidden for Secrets

Symptom

A user with Owner on an Azure Key Vault is refused when reading secrets, with an error such as: The user, group or application does not have secrets list permission.

The answer: under Azure RBAC, Owner and Contributor are management-plane roles. Reading secrets, keys or certificates needs a data-plane role, for example Key Vault Secrets User for reading secret values. Assign it at the narrowest suitable scope, then allow time for propagation and retest.

False Assumption

The assumption is that Owner is the highest role and so implies access to everything inside the vault. It does not. Azure separates the management plane (creating and configuring the vault) from the data plane (the secrets, keys and certificates). With the RBAC permission model, data-plane access comes only from data-plane roles or actions.

Root Cause

The vault uses the Azure RBAC permission model, and the caller holds only management-plane roles. No role assignment covers the data actions the request needs, so the data plane returns Forbidden. Older vaults using access policies behave differently, which is why the same Owner role may appear to work on one vault and fail on another.

Impact

Applications, pipelines and administrators cannot read secrets, and the failure often surfaces after migrating a vault from access policies to RBAC. The tempting fix, granting a broad administrative data role, widens access beyond what is needed. Related cases are covered in RBAC migration bundling purge into Key Vault Administrator and rotation principals inheriting purge.

Diagnosis

Confirm the permission model and the caller’s assignments with read-only commands.

az keyvault show --name VAULT --query properties.enableRbacAuthorization
az role assignment list --assignee PRINCIPAL --scope VAULT_RESOURCE_ID --include-inherited -o table

Observation to expect: the first returns true, and the second lists Owner or Contributor but no Key Vault data role. That combination matches the failure.

Correction

Assign the least-privileged data role at the narrowest scope that works, preferably the vault or a single secret rather than the subscription.

az role assignment create --assignee PRINCIPAL --role "Key Vault Secrets User" --scope VAULT_RESOURCE_ID

Stop if the assignee is not the intended identity or the scope is wider than planned. Use Key Vault Secrets Officer only when the identity must write secrets.

Validation

Role assignments can take several minutes to propagate. Retest with the affected identity: az keyvault secret show --vault-name VAULT --name SECRET should return the secret metadata and value rather than Forbidden. Also confirm the assignment appears in the list command above.

Rollback

To undo the change, delete only the assignment you created, using the same assignee, role and scope: az role assignment delete --assignee PRINCIPAL --role "Key Vault Secrets User" --scope VAULT_RESOURCE_ID. Afterwards the identity should return to Forbidden on secret reads, confirming the original state. Run this as a deliberate, reviewed step; it removes only that assignment.

Prevention

• Treat management and data access as separate grants in role design and templates.
• Grant data roles to workload identities at vault or secret scope, not subscription scope.
• Check the permission model before migrating vaults, and review access using the pattern in workload identity token exchange failures when identities are federated.
• Test each application identity with a real read after any role change.

Next safe decision: if a read still fails after propagation, check for network restrictions on the vault and escalate to the platform owner rather than adding broader roles. Confirm role names and propagation behaviour on the Microsoft Azure Key Vault RBAC guide.