We all know that we need to protect the sensitive configuration values in our applications. Still we spend a lot of time coming up with reasons why we can’t do it properly. We don’t have time. It’s complicated to implement. Nobody will try and hack our application. We can always do it later. Sound familiar?

I’ve said it many times before: There’s nothing more permanent than the temporary. So, if you come up with a temporary solution with the excuses above, you can be sure that it will stick, if it just works. It is definitely better to handle your configuration settings properly right from the start.

That’s why I wrote this post to show you that the proper way is not any harder than any other way that you can think of.

What’s the Proper Way?

As the title of this post implies, the right way to store your sensitive application configuration settings is to store them in Azure Key Vault. Not even your developers have access to the data stored in Key Vault by default. Only the users and applications that you explicitly grant access to can access the secrets.

Solution Overview

I’ll briefly outline the steps you need to take to have your application configuration settings stored in Key Vault. Please note that this only applies when you deploy your application to Azure. When you develop your application locally, you have your configuration settings stored as you normally would, in a JSON file that is typically created for you by the template, when you create an ASP.NET Core or Azure Functions application with Visual Studio. And that’s the beautiful thing about this solution – Your application does not even know that the settings it reads are actually stored in Key Vault!

Please note that any configuration files that include sensitive data MUST NOT be stored in your source control system. You MUST exclude them so that you don’t store them for others to see.

Here are the steps.

1. Enable system assigned identity for your application
2. Create a Key Vault instance
3. Grant the identity of your application read access to secrets in the Key Vault
4. Store your configuration settings in Key Vault
5. Change your application settings to reference the secrets in Key Vault

I’ve explained these steps in more detail below. Just click on the link above to get you to the right section.

Enable System Assigned Identity

The first thing you need to do is to enable a system assigned identity for your application. The system assigned identity is basically a principal object in Azure AD, that can be used like any other principal object.

The same applies to any App Service such as a web application or Azure Functions application. Both can be assigned an identity in the same way. The screenshots below are from a web application, but you find the same Identity settings for a function app under Platform Features.

To turn system assigned identity on, open your web application, and select Identity under Settings, as shown in the picture below.

Switch the status to On, and click Save. Now your web application has an identity in Azure AD. You find it among your other applications, as you can see below.

Create a Key Vault Instance

You need a Key Vault instance to store your configuration settings in. The easiest way to do that is to first make sure that you have Key Vaults available in the left menu. In order to do that, go to All services, and search for Key vaults, and make sure you have marked it as a favourite, as shown below.

Now it’s easy to just select Key vaults from the menu, and create a new instance. Just make sure that you create the Key Vault in the same region with your application, so that your application does not have to go and get the configuration information from the other side of the world.

Grant Key Vault Access to Your Application

Now that you have your application configured with an identity, and a Key Vault instance to store your configuration settings in, you need to grant your application the proper access to the key vault. I’ll assume that in most cases an application only needs read access to configuration information, but you can easily adjust the access, in case you need more.

On the Azure portal, open your Key Vault and go to Access policies under Settings, as shown below.

Note that the only principal granted access by default is the principal that created the key vault. To add a new access policy, click Add Access Policy, and select your application as principal for the policy, as shown below.

Since you will probably store your configuration settings as secrets, and your application is only going to read the settings, it is enough to grant just the Get permission for secrets, as shown below.

When you’re done, click the Add button to add the policy and get back to the Access policies blade. Remember to save the changes to your access policies!

Store Your Settings in Key Vault

To add a secret to your key vault, open the key vault, select Secrets, and click Generate/import.

Then just give your secret a name, and enter the value, and click Create.

Change Your Application Settings to Reference the Secrets in Key Vault

The final step is now to change your application setting to reference the secret in Key Vault, instead of directly storing the secret in the application settings. Open your web application and go to Configuration under Settings.

Open an existing setting or create a new one, as shown below.

The value of your setting follows a special syntax, that points to the secret in Key Vault. It is formatted as:

@Microsoft.KeyVault({secret reference})

You can read more about the syntax for referencing key vault secrets in this way. If you use SecretUri to reference the secret, there’s one thing that I’d like to point out. You can use the URI to point to a particular version of a secret, or just skip the version, and always use the latest version.

If you skip the version identifier, the URI must end with a forward slash!

@Microsoft.KeyVault(SecretUri=https://secure-settings-demo.vault.azure.net/secrets/my-secret/)

So, if you don’t have the forward slash at the end, your application will just get the reference string, and not the setting it references. I used a lot of time trying to figure this out myself, and I hope that you don’t have to bang your head against the wall, like I did. So, remember the forward slash at the end of the URI if you want to reference the latest version of the secret, and not a specific version!

Sample Application

I wrote a very simple ASP.NET Core application based on the Empty ASP.NET Core application template in Visual Studio 2019 that demonstrates this. You find the source code to the application on GitHub.

As you see from the sample code, there’s really nothing special about accessing the configuration settings, and the application does not even know that the settings are actually stored in Key Vault.

Conclusion

I hope that you agree with me that we’re running out of excuses not to store our configuration settings in Key Vault when deploying to Azure. The same principles can naturally be applied to many other types of applications in Azure. As long as the application has a system assigned identity, you can grant it access to Key Vault.

Some of them have a system assigned identity by default, such as Data Factory. Other types of applications require you to enable a system assigned identity, just like with web applications or function applications. One such type of application is Logic Apps.

So, let’s not store sensitive configuration settings directly in the application settings, OK? It’s really this easy to store them in Key Vault.