Keyvault Access Policy
Azalee Rowling
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.
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.
You need only include --secret-permissions, --key-permissions, and --certificate-permissions when assigning permissions to those particular types. The allowable values for , , and are given in the az keyvault set-policy documentation.
You need only include -PermissionsToSecrets, -PermissionsToKeys, and -PermissionsToCertificates when assigning permissions to those particular types. The allowable values for , , and are given in the Set-AzKeyVaultAccessPolicy - Parameters documentation.
Azure Key Vault protects cryptographic keys, certificates (and the private keys associated with the certificates), and secrets (such as connection strings and passwords) in the cloud. When storing sensitive and business critical data, however, you must take steps to maximize the security of your vaults and the data stored in them.
You can reduce the exposure of your vaults by specifying which IP addresses have access to them. The virtual network service endpoints for Azure Key Vault allow you to restrict access to a specified virtual network. The endpoints also allow you to restrict access to a list of IPv4 (internet protocol version 4) address ranges. Any user connecting to your key vault from outside those sources is denied access. For full details, see Virtual network service endpoints for Azure Key Vault
After firewall rules are in effect, users can only read data from Key Vault when their requests originate from allowed virtual networks or IPv4 address ranges. This also applies to accessing Key Vault from the Azure portal. Although users can browse to a key vault from the Azure portal, they might not be able to list keys, secrets, or certificates if their client machine is not in the allowed list. For implementation steps, see Configure Azure Key Vault firewalls and virtual networks
Azure Private Link Service enables you to access Azure Key Vault and Azure hosted customer/partner services over a Private Endpoint in your virtual network. An Azure Private Endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. The private endpoint uses a private IP address from your VNet, effectively bringing the service into your VNet. All traffic to the service can be routed through the private endpoint, so no gateways, NAT devices, ExpressRoute or VPN connections, or public IP addresses are needed. Traffic between your virtual network and the service traverses over the Microsoft backbone network, eliminating exposure from the public Internet. You can connect to an instance of an Azure resource, giving you the highest level of granularity in access control. For implementation steps, see Integrate Key Vault with Azure Private Link
When you create a key vault in an Azure subscription, it's automatically associated with the Microsoft Entra tenant of the subscription. All callers in both planes must register in this tenant and authenticate to access the key vault. In both cases, applications can access Key Vault in three ways:
In all types of access, the application authenticates with Microsoft Entra ID. The application uses any supported authentication method based on the application type. The application acquires a token for a resource in the plane to grant access. The resource is an endpoint in the management or data plane, based on the Azure environment. The application uses the token and sends a REST API request to Key Vault. To learn more, review the whole authentication flow.
Access to a key vault is controlled through two interfaces: the management plane and the data plane. The management plane is where you manage Key Vault itself. Operations in this plane include creating and deleting key vaults, retrieving Key Vault properties, and updating access policies. The data plane is where you work with the data stored in a key vault. You can add, delete, and modify keys, secrets, and certificates.
Both planes use Microsoft Entra ID for authentication. For authorization, the management plane uses Azure role-based access control (Azure RBAC) and the data plane uses a Key Vault access policy and Azure RBAC for Key Vault data plane operations.
To access a key vault in either plane, all callers (users or applications) must have proper authentication and authorization. Authentication establishes the identity of the caller. Authorization determines which operations the caller can execute. Authentication with Key Vault works in conjunction with Microsoft Entra ID, which is responsible for authenticating the identity of any given security principal.
A security principal is an object that represents a user, group, service, or application that's requesting access to Azure resources. Azure assigns a unique object ID to every security principal.
Key Vault provides support for Microsoft Entra Conditional Access policies. By using Conditional Access policies, you can apply the right access controls to Key Vault when needed to keep your organization secure and stay out of your user's way when not needed.
Authorization determines which operations the caller can perform. Authorization in Key Vault uses Azure role-based access control (Azure RBAC) on management plane and either Azure RBAC or Azure Key Vault access policies on data plane.
Applications access the planes through endpoints. The access controls for the two planes work independently. To grant an application access to use keys in a key vault, you grant data plane access by using Azure RBAC or a Key Vault access policy. To grant a user read access to Key Vault properties and tags, but not access to data (keys, secrets, or certificates), you grant management plane access with Azure RBAC.
When you create a key vault in a resource group, you manage access by using Microsoft Entra ID. You grant users or groups the ability to manage the key vaults in a resource group. You can grant access at a specific scope level by assigning the appropriate Azure roles. To grant access to a user to manage key vaults, you assign a predefined key vault Contributor role to the user at a specific scope. The following scopes levels can be assigned to an Azure role:
When using the Access Policy permission model, if a user has Contributor, Key Vault Contributor or other role with Microsoft.KeyVault/vaults/write permissions to a key vault management plane, the user can grant themselves access to the data plane by setting a Key Vault access policy. You should tightly control who has Contributor role access to your key vaults with the Access Policy permission model to ensure that only authorized persons can access and manage your key vaults, keys, secrets, and certificates. It is recommended to use the new Role Based Access Control (RBAC) permission model to avoid this issue. With the RBAC permission model, permission management is limited to 'Owner' and 'User Access Administrator' roles, which allows separation of duties between roles for security operations and general administrative operations.
You can integrate Key Vault with Event Grid to be notified when the status of a key, certificate, or secret stored in key vault has changed. For details, see Monitoring Key Vault with Azure Event Grid
I would like to have a dependsOn statement in another resource in the template referencing the newly created access policy but don't quite know how to construct it. I guess I can't use the resourceId function (as I do in the access policy resource) as the access policy was not created with a specific resourcename (which I would need to pass on to the resourceId function).
Despite adding myself (first for get+list secrets, and then) all keys, secrets and certificates options in the access policies, I am still unable to list any keys, secrets or certificates, nor create any.
I followed the process that Sridevi nicely explained above. At first it didn't work, because I selected items in the Application tab. The second time I created access policy and skipped the Application tab and it worked.
I have an app with 2 slots. I have stored connection strings in the key vault. I have enabled MSI on the app and 2 slots. Also, within the vault's access policy, I have added the app (production slot). However I am not able to add the slots to the access policy. E.g. My app's name is XYZ20180706 and the slots are XYZ20180706/dev and XYZ20180706/test. But when I type in XYZ20180706/dev or XYZ20180706-dev in the service principal, it is not found.
With an Azure Key Vault, RBAC (Role Based Access Control) and Access Policies always leads to confusion. Let me take this opportunity to explain this with a small example. First of all, let me show you with which account I logged into the Azure Portal. You can see this in the graphic on the top right.
In "Check Access" we are looking for a specific person. It is the Jane Ford, we see that Jane has the Contributor right on this subscription. So she can do (almost) everything except change or assign permissions. This is in short the Contributor right.
c80f0f1006