Troubleshooting Azure Key Vault access policy issues

If you're having problem with listing/getting/creating or accessing secret, make sure that you have access policy defined to do that operation: Key Vault Access Policies

After you create one or more key vaults, you'll likely want to monitor how and when your key vaults are accessed, and by whom. You can do monitoring by enabling logging for Azure Key Vault, for step-by-step guide to enable logging, read more.

As you start to scale your service, the number of requests sent to your key vault will rise. Such demand has a potential to increase the latency of your requests and in extreme cases, cause your requests to be throttled which will degrade the performance of your service. You can monitor key vault performance metrics and get alerted for specific thresholds, for step-by-step guide to configure monitoring, read more.

The user needs to have sufficient Microsoft Entra permissions to modify access policy. In this case, the user would need to have higher contributor role.

There are two reasons why you may see an access policy in the Unknown section:

• A previous user had access but that user no longer exists.
• The access policy was added through PowerShell, using the application objectid instead of the service principal.

Assigning roles on individual keys, secrets and certificates should be avoided. Exceptions to general guidance:

Scenarios where individual secrets must be shared between multiple applications, for example, one application needs to access data from the other application

The simplest way to authenticate a cloud-based application to Key Vault is with a managed identity; see Authenticate to Azure Key Vault for details. If you're creating an on-premises application, doing local development, or otherwise unable to use a managed identity, you can instead register a service principal manually and provide access to your key vault using an access control policy. See Assign an access control policy.

Give the AD group permissions to your key vault using the Azure CLI az keyvault set-policy command, or the Azure PowerShell Set-AzKeyVaultAccessPolicy cmdlet. See Assign an access policy - CLI and Assign an access policy - PowerShell.

The application also needs at least one Identity and Access Management (IAM) role assigned to the key vault. Otherwise it will not be able to log in and will fail with insufficient rights to access the subscription. Microsoft Entra groups with Managed Identities may require many hours to refresh tokens and become effective. See Limitation of using managed identities for authorization

Currently Key Vault redeployment deletes any access policy in Key Vault and replaces them with access policy in ARM template. There's no incremental option for Key Vault access policies. To preserve access policies in Key Vault, you need to read existing access policies in Key Vault and populate ARM template with those policies to avoid any access outages.

Another option that can help for this scenario is using Azure RBAC and roles as an alternative to access policies. With Azure RBAC, you can redeploy the key vault without specifying the policy again. You can read more this solution here.

• HTTP 401: Unauthenticated Request - Troubleshooting steps
• HTTP 403: Insufficient Permissions - Troubleshooting steps
• HTTP 429: Too Many Requests - Troubleshooting steps
• Check if you've delete access permission to key vault: See Assign an access policy - CLI, Assign an access policy.
• If you have problem with authenticate to key vault in code, use Authentication SDK

Follow the best practices, documented here

Learn how to troubleshoot key vault authentication errors: Key Vault Troubleshooting Guide.