Introducing the Azure Key Vault

If you need to store secrets in the Azure cloud, such as connection strings, passwords, or even keys, the Key Vault may be for you. In this post I will provide an overview of the Azure Key Vault and discuss certain implementation details to help you determine if the Key Vault is for you.

Service Overview

The Azure Key Vault is a highly secured service allowing you to store sensitive information and even help you with compliance initiatives. The Azure Key Vault is designed to store secrets and keys, including certificates, in a way that is highly secure. In fact, keys stored in the Key Vault are not visible to Microsoft. Developers can manage keys for development and test purposes, while giving control to security operations for production systems. In addition to storing keys and secrets, the Key Vault can also be used to perform cryptographic calculations, so that applications do not actually have access to the keys directly.

You should also note that all operations against the Key Vault are logged so that administrators can monitor usage of keys and secrets.

Scenario 1:  Store Secrets

Storing secrets is perhaps one of the most fundamental capability of the Key Vault; you can store sensitive information, and retrieve it by its name at a later time. You can also ensure that the user or application accessing the secret has the proper authority to doing so.

Scenario 2: Perform Cryptographic Operations

In this scenario, you can store a Key in the Key Vault, and perform Encryption/Decryption operations using the key. This allows an organization to encrypted data using encryption keys that the organization will never have access to. This is particularly interesting for SaaS vendors that are interested in storing encrypted customer data without ever being able to decrypt the information themselves.

Scenario 3: Manage Certificates

Another interesting scenario is the ability to store certificates and let Azure keep an eye on their expiration.

Managing Access to the Key Vault

Storing keys and secrets in the Azure Key Vault is not too hard, and can be performed programmatically or through the Azure Management Portal. In order to use keys and secrets stored in Key Vault, users and applications must be registered in Active Directory. Unlike other services, where a simple access token is all that’s needed to access a service, the Azure Key Vault requires consumers to authenticate against Azure Active Directory first. Once authenticated, consumers can access the Key Vault and perform the operations they are allowed to perform (such as List Keys, Read Secrets…).

To give access to the Key Vault, an administrator must add an Active Directory User, or Active Directory Application, to the list of users for the Vault. Once added, each user is given a set of Access Control List (ACL) with rights to perform certain actions on keys and secrets; there is a separate list of ACLs for keys and secrets. As a result, an application may have read rights to secrets but not keys.

Applications can access the Key Vault using two methods: a secret token, or a certificate. When using a secret token, the application authenticates to Active Directory using its name and the secret token (which acts as a form of password). However you should note that the token can only be valid for up to two years. Alternatively, an application can authenticate against Active Directory using an X.509 certificate, in which case the Active Directory Application must be associated to the X.509 certificate in Azure Active Directory, and the application must find the X.509 Certificate in its local certificate store (locating a X.509 certificate is usually performed by thumbprint). Here is a link to an article that discusses authenticating against Azure Active Directory using a certificate:

However you should note at at this time it is not possible to set an ACL on specific secrets or keys directly. As a result the lowest ACL granularity is at the Key store or Secret store level.

About Herve Roggero

Herve Roggero, Microsoft Azure MVP, @hroggero, is the founder of Enzo Unified ( Herve's experience includes software development, architecture, database administration and senior management with both global corporations and startup companies. Herve holds multiple certifications, including an MCDBA, MCSE, MCSD. He also holds a Master's degree in Business Administration from Indiana University. Herve is the co-author of "PRO SQL Azure" and “PRO SQL Server 2012 Practices” from Apress, a PluralSight author, and runs the Azure Florida Association.