Get started with Azure key vault

Get started with Azure key vault

Azure key vault is a service to store and manage keys, secrects and certificates that you can use for your applications. In this blog post I want to quickly show how to create a key vault and how to use it. Key vault is a secure key management service that allows to manage keys, application secrets and certificates. The keys are stored in hardware security modules (FIPS 140-2 Level 2) and even Microsoft does not see them. Pretty cool stuff, so why should someone use Azure Key Vault? A common problem is how to manage keys and secrets for your applications? Where to store them? And how to ensure that they have a defined lifetime? Azure key vault allows to achieve all these things. A few features are:

It especially helps you to solve the issue of storing keys/secrets for your applications. If you develop an application – where do you put e.g. storage keys or other secrets? Sometimes developers hardcode them into the code. Other developers store them in the configuration (e.g. app.config) and just a few use something like azure key vault.

Ok, but what is a key vault? A key vault is a container for keys and secrets that are managed together. If you develop an application, then it makes sense to create one key vault per application because the access control and also the billing is per key vault. If you have all keys/secrets stored in one key vault, then each user that has access to that key vault can read all keys/secrets that in the key vault. So you should definitely create one key vault per application. As a key vault itself is for free, this shouldn’t be a problem and helps you to secure your stuff. The pricing for key vault is pay per usage of keys (see: Key Vault Pricing Details).

The key vault allows you store:

Key: A cryptographic key (RSA 2048) that you can use to decrypt/sign with the key

Read a secret from a c# application

Reading a secret from a c# application requires a bit more steps, because we will not authenticate as our user but as application. Therefore we need to create an application in Azure AD and add few packages and stuff to our application:

give it a name and a (non-relevant) sign-on url – e.g.: Name: keyvaultapp Sign-on URL: http://localhost/mykeyvaultapp

Save it – open the application and copy the application id (=clientId). Create a new key and copy the value of the key (=clientSecret)

2. step: Permissions for the new application Jump back to the key vault – open the principals and add a new principal (the application we created in the previous step): Leave the template empty, select the application from the previous step as principal and set “Secret permissions” to “Get”:

3. step: Use it in your C# application

Create a new application and add the NuGet packages “Microsoft.Azure.KeyVault” and “Microsoft.IdentityModel.Clients.ActiveDirectory”:

CLIENTID, CLIENTSECRET and SECRETURI should be stored in the application config file. The values for clientid and clientsecret can be found at the Azure Active Directory app registration (see step 1). The secret uri is the uri that you can find at the key vault when you open the secret (Key vault – Secrets – your secret – current version):

So far so good – we can already read a secret from a c# application and also from powershell. This is already useful for many use cases, but there are still a few things to discover. How to authenticate an application with a certificate? How to use key vault from an azure function? How to use keys to encrypt/decrypt? I will write a few more blog posts about azure key vault – so stay tuned!

Thanks Armin for such good explanation! Only have a question that’s confusing me. You say CLIENTID, CLIENTSECRET and SECRETURI should be moved to app.config. My winforms application is distributed to customers. If they use IL-SPY they’ll be able to see the contents of these 3 consts. Will they be able to find out the secret (Azure SQL Server connectionstring password in my case) if they know these 3 consts? If so, what would you suggest to avoid this assuming I’m stuck with winforms for now. Thanks again! Sergio

if possible, I would not directly connect the winforms application to the sql server. It’s better to have an api in between. If you have no other option than connecting directly to azure sql, then you could use azure active directory to authenticate the client user and use the received token to connect to the sql server or to get the secret from key vault. With the key vault option, you could also configure auto rotation – see: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-key-rotation-log-monitoring