RBAC error on Key Vault Secrets

Question

RBAC error on Key Vault Secrets

Venky Swaminathan 0

I am in a security group that has a role "Key Vaults Secrets Officer" assigned to the key vault resource. But when I perform an azure cli operation to set a secret ('Microsoft.KeyVault/vaults/secrets/setSecret/action') : I get a permission error (Inner error: { "code": "ForbiddenByRbac" }. Why?

Shubham Sharma 16,640 Reputation points Microsoft External Staff Moderator

2026-05-28T01:45:56.2933333+00:00
Hey Venky – this is almost always caused by a mismatch between the way your vault is locked down (RBAC vs. legacy access policies) and the type of permission you’ve assigned. A few things to check:

Permission-model on the vault • In the Azure portal go to your Key Vault → Access configuration • If it’s still set to “Vault access policy” then any Azure RBAC roles (Key Vault Secrets Officer, etc.) will be ignored. • Either switch it to “Azure role-based access control” or grant an access policy for SetSecret in the old model.

Correct role for the plane you’re calling • The “Key Vault Secrets Officer” built-in role only covers the Key Vault data-plane (calling the vault’s HTTPS endpoint). • The CLI command you’re running (Microsoft.KeyVault/vaults/secrets/setSecret/action) is a management-plane operation, so you also need an ARM-level role such as Key Vault Contributor (or Owner) on the vault resource itself.

Scope and propagation • If you really only need data-plane az keyvault secret set, make sure you’ve: – Switched the vault to Azure RBAC model – Assigned “Key Vault Secrets Officer” at either the vault scope (/…/providers/Microsoft.KeyVault/vaults/<vault>) or at the individual secret scope (/…/vaults/<vault>/secrets/<secretName>). • After assigning roles, wait a few minutes (and/or re-login) for Azure AD group membership and role assignments to propagate.

Hope that helps!

Reference docs:

Azure Key Vault permission models (access policies vs. Azure RBAC): https://learn.microsoft.com/azure/key-vault/general/rbac-guide?tabs=azure-cli#key-vault-access-model-overview

Built-in Key Vault data-plane roles (Secrets Officer, etc.): https://learn.microsoft.com/azure/key-vault/general/rbac-guide?tabs=azure-cli#azure-built-in-roles-for-key-vault-data-plane-operations

Assigning RBAC roles via Azure CLI / PowerShell / Portal: https://learn.microsoft.com/azure/key-vault/general/rbac-guide

Management-plane roles for Key Vault (Contributor, Owner): https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#key-vault-contributor

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".
Shubham Sharma 16,640 Reputation points Microsoft External Staff Moderator

2026-05-29T08:29:29.11+00:00

Venky Swaminathan

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.

1 answer

Your answer

Shubham Sharma 16,640 Reputation points Microsoft External Staff Moderator

2026-05-29T08:29:29.11+00:00

Venky Swaminathan

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.

Answer 1

The error occurs because the identity that runs the Azure CLI does not effectively have the required Key Vault data-plane permission at the scope where the operation is executed, even though the security group is assigned the “Key Vault Secrets Officer” role on the vault.

Key points from the RBAC model for Key Vault:

Azure RBAC must be enabled for the vault
The new Azure RBAC permission model is an alternative to the legacy access policy model. If the vault is still using the legacy access policy model, data-plane access is controlled by access policies, not by Azure RBAC roles such as “Key Vault Secrets Officer”. In that case, having the RBAC role alone will not grant setSecret and results in ForbiddenByRbac.
Correct scope and role assignment are required
Data-plane operations like Microsoft.KeyVault/vaults/secrets/setSecret/action require a Key Vault data role (for example, “Key Vault Secrets Officer”) assigned at a scope that covers the vault or the specific secret. The CLI identity must be:
- A member of the group that has the role assignment, and
- Accessing the vault where Azure RBAC is the active permission model.
Role assignment propagation and caching
Role assignments can take several minutes to propagate. Browsers and portals cache permissions, and a refresh is sometimes required after adding or removing assignments. If the role was just assigned, the CLI call may temporarily fail with ForbiddenByRbac until propagation completes.
Group-based access and token refresh
When membership in a security group changes, the access token used by Azure CLI may not immediately reflect that membership. A fresh login (az login) is required so that the token includes the updated group claims. Until that happens, Key Vault evaluates the token as if the user is not in the group, resulting in ForbiddenByRbac.

To resolve:

Confirm the vault is using Azure role-based access control as the permission model (not “Vault access policy”).
Verify that the Key Vault Secrets Officer role is assigned at the vault (or secret) scope to the security group.
Ensure the CLI identity is indeed a member of that group and run a fresh az login so the token includes the group membership.
Wait a few minutes for RBAC propagation and retry the az keyvault secret set operation.

If the vault must remain on the legacy access policy model, configure an access policy that grants secret set permissions instead of relying solely on Azure RBAC.

References:

Share via

RBAC error on Key Vault Secrets

1 answer

Your answer