Warning
For improved security, use the Role-Based Access Control (RBAC) permission model instead of access policies when managing Azure Key Vault. RBAC restricts permission management to only the 'Owner' and 'User Access Administrator' roles, ensuring a clear separation between security and administrative tasks. For more information, see What is Azure RBAC? and the Key Vault RBAC Guide.
With the Access Policy permission model, users with the Contributor, Key Vault Contributor, or any role that includes Microsoft.KeyVault/vaults/write permissions can grant themselves data plane access by configuring a Key Vault access policy. This can result in unauthorized access and management of your key vaults, keys, secrets, and certificates. To reduce this risk, limit Contributor role access to key vaults when using the Access Policy model.
A Key Vault access policy determines whether a given security principal, namely a user, application or user group, can perform different operations on Key Vault secrets, keys, and certificates. You can assign access policies using the Azure portal, the Azure CLI, or Azure PowerShell.
Key vault supports up to 1024 access policy entries, with each entry granting a distinct set of permissions to a particular security principal. Because of this limitation, we recommend assigning access policies to groups of users, where possible, rather than individual users. Using groups makes it much easier to manage permissions for multiple people in your organization. For more information, see Manage app and resource access using Microsoft Entra groups.
Assign an access policy
In the Azure portal, navigate to the Key Vault resource.
Select Access policies, then select Create:
Select the permissions you want under Key permissions, Secret permissions, and Certificate permissions.
Under the Principal selection pane, enter the name of the user, app or service principal in the search field and select the appropriate result.
If you're using a managed identity for the app, search for and select the name of the app itself. (For more information on security principals, see Key Vault authentication.
Review the access policy changes and select Create to save the access policy.
Back on the Access policies page, verify that your access policy is listed.
For more information on creating groups in Microsoft Entra ID using the Azure CLI, see az ad group create and az ad group member add.
To run Azure CLI commands locally, install the Azure CLI.
To run commands directly in the cloud, use the Azure Cloud Shell.
Local CLI only: sign in to Azure using az login:
az login
The az login command opens a browser window to gather credentials if needed.
Acquire the object ID
Determine the object ID of the application, group, or user to which you want to assign the access policy:
Applications and other service principals: use the az ad sp list command to retrieve your service principals. Examine the output of the command to determine the object ID of the security principal to which you want to assign the access policy.
az ad sp list --show-mine
Groups: use the az ad group list command, filtering the results with the --display-name parameter:
az ad group list --display-name <search-string>
Users: use the az ad user show command, passing the user's email address in the --id parameter:
az ad user show --id <email-address-of-user>
Assign the access policy
Use the az keyvault set-policy command to assign the desired permissions:
az keyvault set-policy --name myKeyVault --object-id <object-id> --secret-permissions <secret-permissions> --key-permissions <key-permissions> --certificate-permissions <certificate-permissions>
Replace <object-id> with the object ID of your security principal.
You need only include --secret-permissions, --key-permissions, and --certificate-permissions when assigning permissions to those particular types. The allowable values for <secret-permissions>, <key-permissions>, and <certificate-permissions> are given in the az keyvault set-policy documentation.
For more information on creating groups in Microsoft Entra ID using Azure PowerShell, see New-AzADGroup and Add-AzADGroupMember.
To run commands locally, install Azure PowerShell if you haven't already.
To run commands directly in the cloud, use the Azure Cloud Shell.
Local PowerShell only:
Install the Azure Active Directory PowerShell module.
Sign in to Azure:
Connect-AzAccount
Acquire the object ID
Determine the object ID of the application, group, or user to which you want to assign the access policy:
Applications and other service principals: use the Get-AzADServicePrincipal cmdlet with the -SearchString parameter to filter results to the name of the desired service principal:
Get-AzADServicePrincipal -SearchString <search-string>
Groups: use the Get-AzADGroup cmdlet with the -SearchString parameter to filter results to the name of the desired group:
Get-AzADGroup -SearchString <search-string>
In the output, the object ID is listed as Id.
Users: use the Get-AzADUser cmdlet, passing the user's email address to the -UserPrincipalName parameter.
Get-AzAdUser -UserPrincipalName <email-address-of-user>
In the output, the object ID is listed as Id.
Assign the access policy
Use the Set-AzKeyVaultAccessPolicy cmdlet to assign the access policy:
Set-AzKeyVaultAccessPolicy -VaultName <key-vault-name> -ObjectId <Id> -PermissionsToSecrets <secrets-permissions> -PermissionsToKeys <keys-permissions> -PermissionsToCertificates <certificate-permissions
You need only include -PermissionsToSecrets, -PermissionsToKeys, and -PermissionsToCertificates when assigning permissions to those particular types. The allowable values for <secret-permissions>, <key-permissions>, and <certificate-permissions> are given in the Set-AzKeyVaultAccessPolicy - Parameters documentation.
Next steps