Azure Key Vault gives you two ways to control who can access its keys, secrets, and certificates: vault access policies and Azure Role Based Access Control (RBAC). Vault access policies are set directly on each vault, while Azure RBAC uses the broader Azure role system to assign permissions across many resources. Understanding how these models differ helps you choose the right approach for your security and governance needs.
Vault access policies let you grant specific permissions to individual security principals—users, groups, or applications—for a single vault. You define exactly which operations are allowed on keys, secrets, and certificates, such as get, list, create, or delete. Because each policy applies only to that one vault, you must configure each vault separately. This model provides fine-grained control but can become hard to manage when you have many vaults.
Azure RBAC assigns built-in or custom roles to principals at different scopes, from management groups down to an individual vault. Built-in roles like Key Vault Reader, Key Vault Contributor, Key Vault Secrets Officer, and Key Vault Crypto User cover common management and data-plane actions. You can also create custom roles that include only the permissions you need, such as Microsoft.KeyVault/secrets/get/action. RBAC integrates Key Vault access into your overall Azure governance, making it easier to enforce consistent rules across subscriptions.
Role assignment scopes let you apply permissions at the right level to maintain least-privilege access. The broadest scope is a management group, which covers all subscriptions and vaults under it. A subscription scope applies to all vaults in that subscription, a resource group scope limits roles to vaults in a specific group, and the narrowest scope targets a single Key Vault instance. Choosing the smallest scope that still allows the necessary work prevents over-permissioning and reduces security risk.
Azure RBAC is recommended for consistency across your subscription and works well with Azure Policy for compliance. You can still use vault access policies when you need granular control on individual vaults, but using RBAC simplifies management. After you assign or change roles, the Azure Resource Manager cache takes time to refresh, so changes are not immediate. Always monitor audit logs to verify that your permissions model stays secure and follows the principle of least privilege.
Are you a guardian of your domain? Lean how to leverage your aptitude in security to protect Microsoft Azure technologies, with a goal of earning the Microsoft Certified: Azure Security Engineer Associate certification!
Prepare and test your skills
Prepare and test your skills
Vault access policies are configured directly on an individual vault to grant permissions on keys, secrets, and certificates, whereas Azure RBAC assigns roles across broader resource scopes from management groups down to single vaults. While access policies require managing each vault separately, Azure RBAC simplifies administration and integrates access into overall Azure governance.
Built-in roles include Key Vault Reader, Key Vault Contributor, Key Vault Secrets Officer, and Key Vault Crypto User. These roles cover common management and data-plane operations, and administrators can also create custom roles with specific permissions.
Azure RBAC roles can be assigned at the management group, subscription, resource group, or individual Key Vault instance scope. Selecting the smallest scope that allows necessary tasks enforces least-privilege access and reduces security risks across resources.
StudyCerts
StudyCerts