I’ve always thought there were some flaws in how teams manage configuration and secrets throughout an app’s lifecycle. It’s an area that’s often tricky to get right, and which typically increases in complexity over time.

Azure Key Vault made huge progress in cleaning up the chaos of handling secrets, but I always felt the developer experience could be a bit smoother.

I first came across Azure App Configuration a few years ago during its preview phase. It seemed promising, so I decided to take it for a spin. I got a customer to join in, and pretty quickly, it started proving its worth.

For those who haven’t heard about Azure App Configuration, it is a configuration store where you can store keys and references to secrets in your key vault in a centralized location which can be used by all of your distributed services. And in terms of the developer experience it works seamlessly with your own Entra account as long as someone has provided you with the necessary access level.

In addition to this it now has several useful features like labeling, feature flags, snapshots, configuration change without redeploy and improved security by utilizing managed identities. I will go further into the specifics of several key aspects in my next post.

Configuring the service

When creating the resource in the Azure portal you need to provide some basic settings, and which pricing tier you need for your project. You now have three different options.

• Free – 10MB storage, a maximum of 1000 requests per day with no guarantee in terms of throughput, and no SLA. In other words, only meant for development purposes.
• Standard – 1GB of storage with 30 days of revision history. You also get 30 000 requests per hour, and a guaranteed throughput of 300RPS. In addition to this it provides a SLA of 99.95% (if read replica is configured). If you need to integrate your resources in a VNET you need this tier to have private link support as well.
• Premium – Increased storage to 4GB, and a higher throughput without any upper limitations on hourly requests. In addition you will get 99.99% SLA.

In terms of pricing it looks like this:

• Free – Take a guess 😉
• Standard – 1.20$ a day, plus 0.06$ per 10 000 requests, with the first 200 000 requests included.
• Premium – 9.60$ a day, plus 0.06$ per 10 000 requests, with the first 800 000 requests included.

Once your resource is up and running you will see different options on the left menu. To dive straight into the configuration of keys and secrets, you can go to Configuration explorer. Here you can either add a key-value or a key vault reference.

The key-value option will provide you with a form where you provide a key name and a key value. In addition to this you can set a label. Labels can be anything you like, often used for setting which environment it should be available for, but this is up to you. The labels let you do necessary filters on your keys in your code.

The second option is to provide a reference to a key vault. So this would be your option if you are providing a secret. You give your reference a name which is the name of the configuration key you will use in your code, before you select which key vault you want to use, and which secret in the key vault it should reference.

You now have two entries in your app configuration environment that are possible to retrieve by code. The key vault reference will show a small key vault icon, and when inspecting the value you will only see the key vault uri reference.

Another really useful feature is the history which is available in the context menu on each item. This lets you look at the changes of a label and easily restore previous values.

The last section I would like to cover in this introduction to App Configuration is the ability to create and recover snapshots. This can be used just as a single time thing, or as a part of your deployment pipelines for more regular use. Microsoft also provides a built in sandbox to perform test snapshots beforehand to see how the different filters you set work.

After a snapshot is created you can reference specific snapshots directly in your code.

Initial setup for development

So, implementing it into my first project was easy. I just hooked up the Microsoft.Azure.AppConfiguration.AspNetCore and Azure.Identity packages, and added the following configuration in my startup file.

builder.Configuration.AddAzureAppConfiguration(options => { 
  string endpoint = builder.Configuration.Get("Endpoints:AppConf"); 
  options.Connect(new Uri(endpoint), new DefaultAzureCredential()); 
});

If you integrate with Azure Key Vault as well you need to add some additional code for authenticating with the Key Vault.

options.ConfigureKeyVault(options => {
  options.SetCredential(new DefaultAzureCredential());
});

You’re all set for retrieving secrets and they will be easily available through your injected IConfiguration instance.

If you face access issues when debugging the code, you should make sure you are logged in to the correct Azure tenant. This can be achieved through a simple Azure CLI command.

az login --tenant <tenantId>

If some of the developers are missing access to the subscription you need to specify access without subscription through a designated flag like below.

az login --tenant <tenantId> --allow-no-subscriptions

In use

Once you are up and running, config values can easily be fetched in the following way.

public class NodeController(IConfiguration _configuration) : ApiController
{
    [HttpGet]
    public IActionResult GetAllNodes()
    {
        string secret = 
          _configuration.GetValue<string>("SuperSecretFromKeyVault");
          
        //do whatever

        return Ok();
    }
}

Keep in mind that App Configuration won’t automatically take precedence or override other configuration values you’ve set in your app service or app settings files if the key names match.

Based on Microsoft’s documentation the following order is:

1. Command-line arguments using the Command-line configuration provider.
2. Non-prefixed environment variables using the Non-prefixed environment variables configuration provider.
3. User secrets when the app runs in the Development environment.
4. appsettings.{Environment}.json using the JSON configuration provider. For example, appsettings.Production.json and appsettings.Development.json.
5. appsettings.json using the JSON configuration provider.
6. A fallback to the host configuration described in the next section.

Summary

Just like that, you’ve got a centrally managed configuration store, giving you full control over your keys and secrets. No more dev-to-dev, back-and-forth to onboard new developers or share secrets during the development phase. The only thing a developer needs to set up locally is the endpoint for the App Configuration service, which can easily go into the user secrets file, and from there on, everything related to access permissions is managed through the Entra account of the user.