It's a common mistake that every developer tends to make, especially early on: adding secrets to source-control or saving them somewhere else in plain-text. A good example of this is an API key stored in the web.config or settings.json.
Saving secrets as plain-text is a bad-practice can be a security risk. But where should you save your secrets? And how much does it cost to implement an alternative solution?
Azure Key Vault (AKV) is a service provided by Microsoft Azure that lets you store encryption keys, secrets and certificates. AKV can be easily integrated with almost any other service in Azure, but it doesn't stop there. It can easily be integrated in other environments too: local machines, apps, if you want to go crazy you can even use it in an AWS environment.
Make sure to check the pricing of AKV. It's pretty cheap and you can make it cost virtually nothing if you're using caching and minimizing the operations to AKV.
The easiest way to store and retrieve secrets is using the Azure Portal. You give your secret a name, a value and store it. You can retrieve the value of the secret on the same screen. For more complex scenario's, like integrating within your application you can use the REST API or any of the available client-libraries.
When storing secrets, AKV encrypts them and decrypts them when you want to retrieve them. AKV never knows what secret you've stored.
The basic security principle is that you need to authenticated and have the correct authorization level in order to interact with AKV. By default AKV is only accessible by the creator of the AKV. By using access-policies you can give access to other principals.
You can make the AKV even more secure by, for example, adding IP-restrictions or isolating the AKV in a virtual network.
There are two ways you can authenticate to AKV with your application or service. In both cases, you first need to setup an Azure Active Directory (free tier is sufficient!). I'll explain the basic configuration proces, but a more extended tutorial can be found in my GitHub repository, which also includes an example website you can run or deploy.
When you've setup app registration or managed-identity, head over to the Access policies tab in your AKV and grant the correct permissions (get secrets) to the app registration or managed-identity.
Retrieving a secret in code is very easy. This example is based on a .NET application. Using the client-library for .NET we can retrieve a secret with this code:
var client = new SecretClient("<keyvaulturi>", new DefaultAzureCredential()); var secret = await client.GetSecretAsync("mysupersecretsecret");
You can find the URI of your AKV in the Azure Portal. For this to work outside Azure, you will need to set some environment variables:
- AZURE_CLIENT_ID (Client ID from app registration)
- AZURE_TENANT_ID (Tenant ID from app registration)
- AZURE_CLIENT_SECRET (Secret you created in the app registration)
That's it! 🥳
After integrating AKV with your application or service you may have noticed credentials or hints of how your application authenticates with AKV are not stored in your code. The only thing that's saved in the code is the URL of the AKV, but even that can be hidden and saved in an environment variable to make things even more secure.
Another advantage is that all your secrets are stored in one location, instead of possibly multiple locations. This makes management easy.
Speaking of management, by looking at the access-policies of the AKV you can easily identify what and who has access.
✔️ Azure Key Vault (AKV) allows you to safely store secrets, keys and certificates
✔️ Integrating AKV with your application or service is super easy
✔️ Costs virtually nothing, but takes the security of your application or service to the next level