Azure Key Vault provides two authorization models for controlling access to secrets, keys, and certificates: Access Policies and Role-Based Access Control (RBAC).
**Access Policies** represent the legacy authorization model where permissions are granted at the vault level. Each policy defines what…Azure Key Vault provides two authorization models for controlling access to secrets, keys, and certificates: Access Policies and Role-Based Access Control (RBAC).
**Access Policies** represent the legacy authorization model where permissions are granted at the vault level. Each policy defines what operations a security principal (user, group, or service principal) can perform on secrets, keys, and certificates. Permissions include get, list, set, delete, backup, restore, and more. Access policies are configured per Key Vault and apply to all objects of a specific type within that vault. While simple to implement, this model lacks granular control over individual secrets or keys.
**Azure RBAC for Key Vault** offers a more refined approach using Azure's built-in role-based access control system. This model allows permissions at the management plane (vault operations) and data plane (secrets, keys, certificates). Built-in roles include Key Vault Administrator, Key Vault Secrets Officer, Key Vault Crypto Officer, and various reader roles. RBAC enables assignment at subscription, resource group, vault, or individual object level, providing superior granularity.
**Key differences:**
- RBAC supports inheritance from higher scopes
- RBAC integrates with Azure AD Privileged Identity Management for just-in-time access
- Access policies require managing permissions per vault, while RBAC centralizes management
**Microsoft Defender for Cloud** monitors Key Vault configurations, alerting on insecure access patterns, disabled soft-delete, or overly permissive policies. **Microsoft Sentinel** can ingest Key Vault diagnostic logs to detect suspicious access attempts, unusual secret retrieval patterns, or potential credential theft.
**Best practices:**
- Enable RBAC authorization for new vaults
- Follow least privilege principles
- Enable diagnostic logging to Log Analytics
- Use managed identities for Azure service authentication
- Enable soft-delete and purge protection
Both models can coexist during migration, but Microsoft recommends RBAC for enhanced security and management capabilities.
Key Vault Access Policies and RBAC: Complete Guide for AZ-500
Why Key Vault Access Policies and RBAC Are Important
Azure Key Vault is a critical service for storing and managing secrets, keys, and certificates securely. Understanding how to control access to Key Vault is essential for the AZ-500 exam because improper access management can lead to security breaches, unauthorized data access, and compliance violations. As a Security Engineer, you must know how to implement the principle of least privilege when granting access to sensitive cryptographic assets.
What Are Key Vault Access Policies and RBAC?
Azure Key Vault supports two permission models for controlling access:
1. Vault Access Policies (Legacy Model) Access policies are configured at the vault level and define which security principals (users, groups, applications) can perform specific operations on secrets, keys, and certificates. Each vault can have up to 1,024 access policy entries.
2. Azure RBAC (Recommended Model) Azure Role-Based Access Control provides fine-grained access management using Azure's built-in roles or custom roles. RBAC operates at the management plane and data plane, offering more granular control and centralized permission management through Azure Active Directory.
How Key Vault Access Control Works
Access Policy Model: - Permissions are granted for keys, secrets, and certificates separately - Operations include get, list, set, delete, backup, restore, recover, and purge - Access policies apply to all objects of a type within the vault - No inheritance from parent scopes
Azure RBAC Model: - Uses built-in roles like Key Vault Administrator, Key Vault Secrets Officer, Key Vault Crypto Officer, and Key Vault Reader - Permissions can be assigned at management group, subscription, resource group, or individual vault level - Supports custom role definitions - Integrates with Azure AD Privileged Identity Management (PIM) for just-in-time access
Key Built-in RBAC Roles for Key Vault: - Key Vault Administrator: Full access to manage vault and all objects - Key Vault Secrets Officer: Perform any action on secrets - Key Vault Secrets User: Read secret contents - Key Vault Crypto Officer: Perform any action on keys - Key Vault Certificates Officer: Manage certificates - Key Vault Reader: Read metadata of vaults and objects
Switching Between Permission Models
You can switch between access policies and RBAC in the Key Vault settings under Access configuration. When you switch to RBAC, existing access policies are retained but not enforced. You can switch back if needed, and the policies will become active again.
Exam Tips: Answering Questions on Key Vault Access Policies and RBAC
1. Know the recommendation: Microsoft recommends Azure RBAC over access policies for new deployments. If a question asks for the best practice or recommended approach, choose RBAC.
2. Understand scope differences: Access policies only work at the individual vault level, while RBAC can be assigned at higher scopes (subscription, resource group) for centralized management.
3. Remember the 1,024 limit: Access policies have a maximum of 1,024 entries per vault. If a scenario mentions scaling issues or many applications needing access, RBAC is the solution.
4. PIM integration: Questions about just-in-time access or time-limited permissions require RBAC because access policies do not integrate with Privileged Identity Management.
5. Separate plane access: Management plane operations (creating vaults, configuring settings) always use RBAC. Data plane operations (accessing secrets, keys) can use either model.
6. Application access: When applications need Key Vault access, look for managed identities combined with either access policies or RBAC roles.
7. Granularity matters: If the question requires access to a specific secret rather than all secrets, RBAC provides more granular control.
8. Watch for hybrid scenarios: You cannot use both permission models simultaneously on the same vault. Only one model is active at a time.
9. Audit and compliance: RBAC integrates better with Azure Activity logs and provides unified access management across Azure resources, making it preferable for compliance scenarios.