What is the point of Azure App Config KeyVault references?

Question

In Azure you can setup an App Config and a KeyVault. The point of the KeyVault being to store more sensitive data than your App Config and be able to regulate access to the config and vault separately.

So what is the benefit of using a keyvault reference in the app config?

You are basically allowing anyone with access to the app config to access certain values in your keyvault and are bypassing the additional layer of security the vault normally provides.
The additional layer being required auth to the vault to access those same values if they aren't referenced in the config.

I really don't understand what benefit keyvault references give you.

score 6 · Accepted Answer · answered Sep 29 '21 at 05:40

This blog article by Jan de Vries explains them in more detail: https://jan-v.nl/post/2021/using-key-vault-with-azure-app-configuration/.

The relevant part for your question:

As it happens, the code for accessing App Configuration doesn’t give your application permission to retrieve secrets from Key Vault.

The application retrieves them from Key Vault, not from App Configuration. App Config only holds the reference, not the actual value.

Official docs also mention this:

Your application uses the App Configuration client provider to retrieve Key Vault references, just as it does for any other keys stored in App Configuration. In this case, the values stored in App Configuration are URIs that reference the values in the Key Vault. They are not Key Vault values or credentials. Because the client provider recognizes the keys as Key Vault references, it uses Key Vault to retrieve their values.

Your application is responsible for authenticating properly to both App Configuration and Key Vault. The two services don't communicate directly.

score 0 · Answer 2 · answered Apr 27 '23 at 11:37

I need to clarify something that @juunas said,

The application retrieves them from Key Vault, not from App Configuration. App Config only holds the reference, not the actual value.

This isn't entirely true, as you can actually 'query' the appservice from within the advanced tools for the actual value. To do this, follow these steps:

Open up your appservice in Azure
Go to Advanced Tools (under Development Tools)
From within that menu, open the drop-down menu Debug console. Pick CMD
Write env in the command-prompt

This will give you all the variables that the container is currently configured with. Azure secrets aren't obscured by their SecretName, the Value shows clearly.

Conclusion While it is partially true that the Configuration doesn't reveal the secret since its value is hidden using the KeyVault URL (which looks something like '@Microsoft.KeyVault(SecretUri=https://{your-keyvault-name}.vault.azure.net/secrets/{secret-name}/)' it is still held from within the container itself and can be queried.

I think it's important to note this because a lot of people think that their secrets aren't available, and that can lead to security incidents if they aren't careful enough.

score -1 · Answer 3 · answered Sep 29 '21 at 06:22

I suppose there are different approaches to using the KeyVault, but the way I tend to use it is as follows.

My application will have a set of secrets, which I store locally using the Secrets Manager, you would add the secret for your application:

dotnet user-secrets set "Movies:ServiceApiKey" "12345"

Your application can then read this setting using _moviesApiKey = Configuration["Movies:ServiceApiKey"]; as you'll see in the link above. Obviously, there's no way you can see this value in the code, but your application can read it from the Secrets Manager.

If you do forget the values, you can use the following command to retrieve them:

dotnet user-secrets list

KeyVault will work as your Secrets Manager within Azure. So, your application will need to have permission to access the KeyVault, and in my case I store the Vault name in the appsettings.json, and during the bootstrapping, I include the KeyVault configuration if running in Production mode i.e. on the Azure Server and not locally.

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
      WebHost.CreateDefaultBuilder(args)
        .ConfigureLogging(logging =>
        {
          logging.ClearProviders();
          logging.AddConsole();
          logging.AddAzureWebAppDiagnostics();
        })
        .ConfigureAppConfiguration((context, config) =>
        {
          if (context.HostingEnvironment.IsProduction())
          {
            IConfigurationRoot builtConfig = config.Build();
            ConfigurationBuilder keyVaultConfigBuilder = new ConfigurationBuilder();
            keyVaultConfigBuilder.AddAzureKeyVault(builtConfig["VaultName"]);
            IConfigurationRoot keyVaultConfig = keyVaultConfigBuilder.Build();
            config.AddConfiguration(keyVaultConfig);
          }

        })
        .UseStartup<Startup>();

Note, the check for context.HostingEnvironment.IsProduction(). Within the appsettings, I have:

"VaultName": "https://yourkvname.vault.azure.net/"

So, the only reference I have to the KeyVault from the application is the name, and that should be secure as only the application will have access to the keys/secrets.

One thing to note, you need to make sure that the names match both for your local secrets and the ones in the KeyVault. In my case, I am running on a Windows platform, so I needed to make a small change to the names using double dashes (--) in place of the colon (:), so...

Movies:ServiceApiKey

Becomes

Movies--ServiceApiKey

score -1 · Answer 4 · answered Sep 29 '21 at 11:57

When working in Azure, storing secrets in Key Vault is a good idea. And to make it better, there’s the Key Vault Reference notation. This feature makes sure no one can read the secret(s) unless someone grants permission.

Speaking of secrets, they should never be directly stored in application settings of a Function App (same goes for App Services by the way). Why not ? Because secrets would be available to anyone who has access to the Function App in the Azure Portal. The right way is to use an Azure Key Vault which is the Azure component for securely storing and accessing secrets . Once your secrets are in the key vault, you have to grant the Key Vault access to the identity of your Function App and you can then reference the secrets you need directly in your application settings. These are called Key Vault references because an application setting does not contain directly the value of a secret but a reference to the secret which is stored in Key Vault. When running, your function will automatically have access to the secret and its value as an environment variable, as if it was a normal application setting.

Key Vault references work for both App Services and Function Apps and are particularly useful for existing applications that have their secrets stored in settings because securing the secrets with Azure Key Vault references does not require any code change.

Reference: https://www.techwatching.dev/posts/azure-functions-custom-configuration

https://www.sharepointeurope.com/using-key-vault-references-with-azure-app-configuration/

What is the point of Azure App Config KeyVault references?

4 Answers4