What is Azure Key Vault?

In this blog post, we will be talking about Azure Key Vault, a cloud solution from Microsoft that sits inside your Azure subscription. You can think about it as secure store as a service for your secrets and keys.

The need for a secure store?

When an employee leaves the company, you want his access to secrets and keys to be revoked easily from one place, and handed over to the new employee. This means that the keys should not be available for employees to read, but still available for them to use.

Keys also should be easily rotate. This means that an administrator should log on at any time, and for any reason, and change the content of the key, while still allowing the users and applications to have access to the new key material

Usually secrets or connection strings are stored in your application configuration file, which is not the most secure option here. If you want to share you code or upload it to GitHub, this means that your secrets are available to developers and users.

Moreover, if you are using keys for encryption, most likely that the key will be available in memory while you are doing your key operations. If your VM get compromised, you will be in bad share. In high secure environment, your sensitive data should be sent to a secure service to do the cryptographic operations, without exposing the private key to the machine or without having a copy of your key in memory.

Nowadays, there is a need to:

Have inventory for your secrets.

Have a specialized store for secrets and key.

Use professional identity service to govern access to your secrets/keys.

Have flexible permission model to grant just enough permissions to the right entities.

Log mechanism and access reviews.

A way to rotate keys frequently.

Automation built in to provision and rotate keys.

There is a clear need to have secret store as a service, so that you can store and manage secrets, and a way to isolate cryptographic keys. Such service would also offer storing keys in HSMs for you, so that your keys never get out the HSM device and will never be exposed to applications, or in the memory of virtual machines.

What is Azure Key Vault ?

Azure Key Vault is a PaaS platform in Azure, that is integrated into Azure Active Directory, and provides generation and storage of keys, audit logs, and is compliant to FIPS 140-2 [US Government Security] as well as Common Criteria [International Standard].

Azure Key Vault stores secrets and keys. Secrets are the less secure usage of Azure Key Vault. They are text that can be long as 25kb in size, and they are stored and retrieved the same way they are sent to the Azure Key Vault. This means you can store plain text passwords, connection strings, JSON, XML and more.

You can also store keys into the Azure key vault. A key contains public and private portions. Azure Key Vault will generate and store both parts, but will never disclose the private key, not to a user and not to an application. This is a huge security benefit by its own, as no one in your organization will ever see the private portion of the key.

Another interesting scenario would be the use of symmetric keys. You can use symmetric keys to encrypt storage and SQL data, and then wrap that symmetric key by encrypting it with asymmetric key. Once your symmetric key is wrapped, it can be safely stored inside the key vault.

Since the private key never leaves the key vault, you need to run all your encryption, decryption and wrapping operations inside Azure Key Vault. This means for example sending an encrypted payload to the Key Vault API, specifying the decryption key to be used, and receiving the decrypted content to the client. What this means is that the Azure Key Vault audit log will list all operations performed using your keys, and will give you a great insight on who is using your data and how it is being used.

Azure Key Vault has a unique versioning engine. This allows you to archive all your secrets and keys, and retrieve them later using a version ID. Hence, your application can use a new key to do encryption operations, while have access to old keys for decrypting data that was previously encrypted with old version of your key.

Azure Key Vault can help you meet regulatory requirements. To do that, you need to store your keys inside hardware security modules [HSM]. HSM is a specialized piece of hardware storage, that is tamper resistant physically and digitally. Not even Microsoft technical team can access your key material.

Also, secrets nowadays [like password, SQL connection strings] are most likely located in your application config files, and if you use GitHub, then your secrets are exposed. A better solution would be to put your secrets in a secure store, and put a reference for the secret in the config file. At run time, the application will use the reference to talk to that secure store, authentication, and finally get access to the secret at run time.

That way, when you deploy an application, there is nothing in the application deployment package that can be marked as sensitive data, only at run time, the application get access to secrets/keys or connection string.

Azure Key Vault Offering

Azure Key Vault is offered as an Azure Resource Provider. At the very top, you have Azure Active Directory, and then you have subscriptions. Inside each subscription you have resource groups. Resource groups contain resources like (VMs, Storage Accounts, and the Azure Key vault).

Azure Key Vault Availability

Azure Key Vault is available worldwide across Azure global regions. When you create your application, it is highly recommended to provision a key vault inside the same region that your application is hosted in. This mean you will be dealing with local network traffic and not cross Azure regions traffic.

When you create an Azure Key Vault inside a region, your secrets and keys in that key vault are stored inside that region, and backed up in a second region within the same geo. You will have three copies of your secrets/keys inside a region, and another three copies in another region in the same geo. If the region where your vault is located went down for any reason, Microsoft will route the vault URI to the other region in the same geo automatically.

Azure Key Vault Version Engine

Azure Key Vault contains Secrets and Keys. Every time you upload a secret or a key to the vault, Azure will maintain a version history for you. This becomes handy for encryption scenarios, where you always rotate your encryption keys, and performing encryption using the latest key, but you still need the old keys to do the decryption for the data that was encrypted using an old encryption key.

Azure Key Vault Integration with Azure AD

Another key thing to mention here, is that all access the vault and its secrets/key are anchored to Azure Active Directory. Any user or application accessing the vault, needs an access token from Azure AD. On each Azure Key Vault that you create, you set permissions that are expressed in terms of Azure AD identities. If you need different identities to access different set of keys, then you can create more than one vault, and lock the permissions accordingly.

Azure Key Vault REST API/ SDK/ PSH/ CLI

Every vault that you create will have a REST API [https://ValtName.vault.azure.net]. This URI [DNS name] is unique globally, and it will identify your vault globally. You can HTTP GET or PUT to that URI.

Every secret that you add to the vault has its own restful URI which is the URI of the key vault, followed by the word [secrets], followed by the name of your secret. Example would be [https://ValtName.vault.azure.net/secrets/MyVMPassword].

Since the vault will keep version history for each key/secret you add, every time you add a secret to the vault, the vault will create a GUID for that secret, and give you back the version specific URI for your secret [https://ValtName.vault.azure.net/secrets/MyVMPassword/552dac27-c352-46f0-8257-3657ea5f0aa3]. From that point, you can access your secret using that version specific URI.

If you tried to access your secret using its name without specifying a version GUID [https://ValtName.vault.azure.net/secrets/MyVMPassword], you will get the latest version of your secret.

Same thing for the keys. You access keys by using this URI [https://ValtName.vault.azure.net/keys], when you add a key called [MyKey] to the vault, it will be located using this URI [https://ValtName.vault.azure.net/keys/MyKey]. You will also get a version specific URI, same as secrets.

Azure Key Vault mode of operation

Distribute secrets via Azure Resource Manager

You can use Azure Resource Manager (ARM) to distribute keys and secrets. You can have ARM read secrets from your key vault and pass them as parameters to the resources you are creating. To do that, we need to grant ARM a special permission to your key vault [The permission name is EnabledForTemplateDeployment].

So during deploying of VMs, you can inject the VM Admin password inside your ARM template, and this will cause ARM to pick up the admin password from the key vault at provision time. Same with SQL Server Admin password.

Distribute certificates to VMs/Web apps

Azure Compute can also deploy certificate from your vault to your VMs “just-in-time” when the VM launches. You can also trigger it to pre-deploy certificate if you update them in your key vault. Similar flow exists with Azure Web Apps.

This becomes handy when you have a lot of VMs and you do not want to manage the certificates on each VM. You can think of the Azure key vault as the local certificate store for your subscription. One place to manage and renew your certificates.

This works for Windows VMs and Linux VMs, so you can ask Azure Compute to place the certificates on any local certificate store on your Windows VM, or in case of Linux, you can pick the location inside your Linux machine.

To do that, we need to grant a special permission for Azure Compute service inside your key vault [The permission name is EnabledForDeployment].

Read/write other secrets directly

Your application might need to access the vault and do cryptographic operations on the fly. To do that, your application should authenticate to Azure AD to get an access token, by registering a service principal for your application first. Check my blog post [Azure Key Vault with PowerShell] to get more insight of how to create an application identity, and consume the key vault from within your PowerShell script.

Creating Azure Key Vault

Creating a key vault is an easy task. It is better to create your key vault in the same Azure region as your applications that are going to consume it. To create a key vault from the Azure Portal, search for Key Vault, and click Add.

You will be asked to enter a name for your key vault, a subscription, resource group and a region. Then you will be asked to choose a pricing tier. Currently, there are two pricing tiers:

Standard tier.

Premium tier [This one allows you to store keys in HSM security modules].

After that you can choose Access Policies, to see who has access to your key vault. We will leave this without any changes now, and we can configure the access policies later. Finally, you can configure the Advanced Access Policy. Those are the policies that we talked about earlier. Each one of those policies will allow the key vault to be consumed by a different service, like Azure Resource Manager, and Azure compute.

You can also use PowerShell to create a key vault. You should have the AzureRM PowerShell module imported into your session first.

You have Successfully Subscribed!

About The Author

Ammar is a digital transformer, cloud architect, public speaker and blogger.
He is considered a trusted advisory with the ability to quickly navigate complex multi-cultural organizations and continuously improve and motivate cross-functional teams to achieve higher productivity, collaboration, revenue gain and cross-group knowledge sharing.
His contributions to the tech community helped him get awarded the Microsoft Most Valuable Professional.
Ammar appears in a lot of global conferences, and he has many publications about digital transformation and next generation technologies.