Hi!
I'm successfully retrieving a Key Vault secret in an ASP.NET Core 2 web app when running locally, but when deployed to an Azure web app, I get this:
[Critical] Microsoft.AspNetCore.Hosting.Internal.WebHost: Application startup exception
Microsoft.Azure.KeyVault.Models.KeyVaultErrorException: Access denied
at Microsoft.Azure.KeyVault.KeyVaultClient.<GetSecretsWithHttpMessagesAsync>d__66.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
at Microsoft.Azure.KeyVault.KeyVaultClientExtensions.<GetSecretsAsync>d__49.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Microsoft.Extensions.Configuration.AzureKeyVault.AzureKeyVaultConfigurationProvider.<LoadAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable.ConfiguredTaskAwaiter.GetResult()
at Microsoft.Extensions.Configuration.AzureKeyVault.AzureKeyVaultConfigurationProvider.Load()
at Microsoft.Extensions.Configuration.ConfigurationRoot..ctor(IList`1 providers)
at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
at IdentityServer.Startup.ConfigureServices(IServiceCollection services)
In Startup.cs, I'm doing this:
public void ConfigureServices(IServiceCollection services)
{
var keyVaultClient =
new KeyVaultClient(
new KeyVaultClient.AuthenticationCallback(new AzureServiceTokenProvider().KeyVaultTokenCallback));
var configuration = new ConfigurationBuilder()
.AddEnvironmentVariables()
.AddUserSecrets<Startup>()
.AddAzureKeyVault("https://[redacted].vault.azure.net/", keyVaultClient, new DefaultKeyVaultSecretManager())
.Build();
...
I have more or less followed this:
https://jeremylindsayni.wordpress.com/2018/03/19/simplifying-azure-key-vault-and-net-core-web-app-includes-nuget-package/
To be precise, I have enabled "Managed service identity", and I have added a Key Vault access policy with the name of the app under "Select principal" as well as "Authorized application". I have selected all secret permissions. I have tried restarting the web app.
I have not run any PowerShell command. Do I still have to?
This is with Microsoft.Azure.Services.AppAuthentication v1.1.0-preview.
I think I found the problem: When adding the access policy, there's a field for "Select principal" and another for "Authorized application". In both cases the app name can be selected, but the trick is to leave the second one blank!
This could certainly be improved with some extra guidance, and a more helpful error message.
I am also unable to sucessfully access my Key Vault Secret from my Azure Function (v2)
I enabled Managed Service identity (MSI)
and added the Azure Function on Access control (IAM)
I am getting Access Denied
I used this code:
var vault_url = "https://mySECRETkeyvault.vault.azure.net/";
var azureServiceTokenProvider = new AzureServiceTokenProvider();
var kvClient = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback), client);
fbAppSecret = (await kvClient.GetSecretAsync(vault_url, "facebook-appid-secret-...")).Value;
See https://stackoverflow.com/questions/49836145/how-to-use-azure-key-vault-from-azure-functions-v2
@torhovland A very big thanks .You made my day. Definitely need guidance here
I experienced the same issue with a similar exception message. The issue was resolved by choosing the other of two identically named Principal entries.

@torhovland , can you please close the issue? thanks!
Thanks for the info, @torhovland. We struggled days before we found out this one. We totally agree that this should be fixed. In our opinion both with a better error message and by not erring when that field is set correctly. (We used powershell to set the access policies.)
Thanks @austvik , @torhovland for reporting this. We will get to a better error message.
@schaabs, for fyi
Phew, I've just spent two hours of my customer's time with figuring this one out. We certainly do need a quick fix here! Many thank @torhovland for reporting this, you've made my day. :)
Many thanks, to @torhovland, you rock!
This comment is not related to the question, but someone could run into an issue, a reference to the key vault in the virtual network still is not allowed. https://github.com/MicrosoftDocs/azure-docs/issues/44567
Hi, I faced the same issue and gave the access policy to my app manually using azure portal. It was not working and throwing an error saying "Access denied. Caller was not found on any access policy". Then I tried to give access policy through PowerShell using "Set-AzureRmKeyVaultAccessPolicy -VaultName -Keyvaultname ObjectId xxxxxx -PermissionsToKeys Create,Get,Decrypt,UnwrapKey,WrapKey,List,Verify,Encrypt" and it worked out.
I think its a bug that they should work on.
Closing this out as this refers to the legacy version of the KeyVault library and there has been no recent engagement. Please feel free to reopen or file a new issue if this remains a problem with the current version of the library.
Most helpful comment
I think I found the problem: When adding the access policy, there's a field for "Select principal" and another for "Authorized application". In both cases the app name can be selected, but the trick is to leave the second one blank!
This could certainly be improved with some extra guidance, and a more helpful error message.