Even though we have a great documentation for each of the azure offerings available, it is our job to study all of the options, compare and choose the one which best suits our application needs.
Configuring application settings for Azure Web App is one such topic where we have multiple options to maintain these settings. Let’s look at those options and see when to use what.
The first obvious place where you can configure all your application settings and connection strings is web.config file which would be part of your application package.
we have been using this file to store all the settings which will impact our application behavior. Few examples of what we can store in this file would be like API or other external Uri’s, database connection strings, secrets or keys, connection strings for other azure/3rd party services and infact anything which should be able to configured at a later point of time without touching the application code.
But, it is not good for storing secrets, keys and connection strings of non-development environment in this file as it would be directly available for developer who is working on the application.
So, what is the other option we have to store these secrets without exposing them to all the members in the team?
Application Settings (in Azure Portal)
This works as a layer on top of web.config file in the application package. which means that any setting we configure in Application Settings blade of Azure Web App will override the existing setting present in web.config file (if any).
This way, all the actual secrets, keys and connection strings can be hidden from the team except those who deal with Azure Provisioning and Releases.
So, we can store all common settings in web.config and store secrets, keys and connection strings within Azure Web App Application Settings as a best practice.
This is similar to how we maintain web.config transform files. App Settings in Azure Portal is like Release version of web.config.
Do we have any other options apart from this to store application secrets and keys?
Let’s think of a scenario where in you’re moving your application to production and you do not want any of the DevOps teams to know the production Keys, Secrets and Connection strings.
you got anything in mind?
Azure Key Vault
Yes, we have Azure Key Vault offering from Microsoft Azure to safeguard secrets, keys and connection strings of all the cloud applications and services.
With Azure Key Vault, you can store all the secrets and cryptographic keys in it and just expose them as a REST Uri to consume from the application without actually exposing the values stored in it.
Also, in order to use this service, you must register your application with Azure AD and provide the AD token to KeyVault every time you want to read a key value, which add an extra layer of security to your application secrets and keys.
This would be a recommended offering provided by azure for all the secrets and keys of production applications.
Hope you enjoyed reading this post and let me know if there are any other better ways to do this. I would be happy to learn.