Storing application secrets in Azure key vault

Most of the time we need to keep certain secrets (like passwords ) and encryption keys configurable as part of applications.Usually this stuff goes in an application configuration file (e.g. app.config or web.config file for .net applications).

This approach has lot of disadvantages like

• Keys and secrets are available in config files and can me misused by a person with malicious intent
• Multiple instances of your application need to use copy of this configuration file and is less scalable
• Changes in any of these values require redeployment of application
• For a multi tenant application you don’t want the headache and responsibility of managing client’s secrets.
  • Clients should manage their own keys and developers should have means to use these keys without actually knowing what these secrets and keys are.
• Keys and secrets are getting replicated in all the applications that need it rather than being managed centrally
• There is no control over who is accessing keys and when as they are openly sitting on a web or app server.

Better way of doing this is using Azure key vault which is used to manage cryptographic keys and secrets centrally ( it could be your connection strings, passwords, .pfx files etc). Azure key vault keeps all the secrets encrypted using HSM backed keys and only allows authenticated access to these keys and secrets. Using Azure key vault for storing secrets is also one of the best practices and implementation of a cloud design pattern known as ‘External configuration store pattern’.

Lets see how to add a database connection string (which we usually store in our config files and is one of the secret information ) to a key vault and how to access it. For this we need to create  key vault,add our secret to the key vault, configure application to use Azure AD authentication and then grant permission to this application in key vault to use secrets and keys.

1.Go to Azure portal and create new Key vault

 

2.  Enter the required information and select the pricing tier.

If you choose Standard tier you can only create secrets and software protected keys where as in case of premium you can also create HSM protected keys.

Let me make this a little clearer. In case of both software and HSM keys the keys are stored in HSM but whenever a cryptographic operation has to be performed using a software key it is retrieved and operation is performed in a compute VM where as for HSM key it is all done within a HSM.

 

3. Create a new secret and give it a name and add its value (in our case that would be a dummy connection string ).

Now this connection string is stored encrypted inside the Key vault and is identified by URI as shown below

 

 

4. Next step is to register the application which want to use this secret to be registered with azure active directory.

You can refer my existing post for the same.

 

5. Next you need to authorize the application to use the required secret. For this go to your Key vault > Access policies and add a new principal ( by default only the user who created the key vault would be added) and select the application you integrated with azure active directory in step 4.

 

You can also provide fine grained permission on what this application should be able to do with keys , secrets and certificates

This completes the configuration and now your application can use the configured secret.

For further learning , here is an excellent pluralsight course covering design and implementation related cloud  patterns and for in-depth coverage of azure key vault another course specific to key vault.