The last two weeks, we’ve been studying ASP.NET’s (and generally speaking, dotnet’s) configuration system. I also eluded to an older blog post that I did on Azure’s App Configuration service which seamlessly allows the management of configuration for dotnet applications running in Azure. If you need a refresher, here are those posts:
- An Introduction to ASP.NET’s Configuration System – Part 1
- An Introduction to ASP.NET’s Configuration System – Part 2
- Change ASP.NET Configuration Parameters on the Fly with Azure App Configuration
In today’s post, we’ll look at a somewhat related service that we find in Azure – Azure Key Vault. It is a service that allows you to store and manage cryptographic keys, certificates, and secrets. It provides a secure way to store sensitive information, such as connection strings, passwords, and other credentials, and makes them accessible only to authorized applications and users.
But, wait a minute! Isn’t that what Azure App Configuration is for ?!? Well, the answer to that is a bit nuanced.
First of all, I want to stress that Azure App Configuration is not an insecure service by any means. Any information that you store in it is automatically encrypted, both at rest and in transit. However, you may come across a use-case where you want to use both these services in a complimentary fashion.
Here’s an example scenario: Say you have a consulting team working on a web application that needs access to a particular database or an external API. However, due to security and/or organizational constraints, you don’t want to simply handover the passwords to those resources but control access in a more fine-grained manner. Well, one way you can achieve this is by providing a key-vault reference. This reference is a pointer to a secret but not the secret itself. The web app team can include this reference in their Azure App Configuration instance and at runtime, when the application needs access to that secret, it will retrieve that secret value for use. Let’s take a look at this in action.
Create a Key Vault Instance
In the Azure portal’s marketplace, search for and select Key Vault. Click on the create button to setup a new instance.
Select your subscription, resource group, region and provide a name for your instance.
Click through the remainder of the setup wizard, keeping all defaults. Create your new resource. Once the deployment is complete (usually takes less than a minute), navigate to your new resource.
Once you have created the Key Vault instance, you can add secrets, such as connection strings, passwords, and other credentials, to it. You can use the Azure portal, Azure CLI, or Azure PowerShell to add secrets to your Key Vault instance. From the secrets menu item, click on the Generate/Import button to setup a new secret. Provide a name for your secret and enter your secret value. You can optionally choose to set a date when the secret should be activated; you can also optionally set an expiration date for this entity.
Grant Access to Azure App Configuration
To access the secrets stored in Azure Key Vault, you need to grant access to Azure App Configuration. You can do this by creating a managed identity for Azure App Configuration and granting it access to your Key Vault instance.
Firstly, you need to turn on managed identity for your App Configuration instance. For that, navigate to your instance, select the Identity tab and turn the status On. You can go with either the System assigned or User assigned option. For this demo, I’m choosing the System assigned option.
By doing this, you have essentially registered this instance with Azure Active Directory allowing you to then assign it permissions from other resources. Next, head over to your Key Vault instance. Here, you want to create an Access Policy to allow your App Configuration access. From the Access policies tab, click on the Create button.
Select the permissions that you want to give to your Azure App Configuration instance. Here, I’m selecting just the Get permission that allows App Config to retrieve a secret. Next, search for and select the application principal that you setup earlier.
Create the policy and it should now be listed as an application in your Access policies list.
Referencing Your New Secret in Azure App Configuration
Now you’re ready to retrieve this secret via App Configuration. Head on over to your App Configuration instance and from the Configuration explorer blade, click the create button. Select the Key Vault reference option.
Here, you can reference your Key Vault instance and reference the secret that you created within it.
That’s it! Now as far as your application is concerned, you can treat this key/value pair just like you would any other configuration value.
Closing Remarks
If you’re running your app in azure and are looking for a flexible configuration solution to inject in environment specific values at runtime, Azure App Configuration is it. It seamlessly plugs in with dotnet’s configuration system, has built-in mechanisms to store simple one-line key/value targets or more complex hierarchical structures and even target multiple environments (via labels). It scales quite well and has generous API limits. It is secure out of the box, encrypting all values both at rest and during transit. Now, if you want to offload your actual secrets to another entity and have further fine-grained control over its access, plug in Azure Key Vault. As you hopefully saw from this post, they play well with each other and you can daisy chain them with little effort. Also check out the many other features of Key Vault as I’ve only covered the relevant bits in terms of storing configuration values/secrets for a web application in this post.