Capsulized overview of Azure Key Vault

Published in

Walmart Global Tech Blog

7 min readSep 16, 2019

Secret management is one of the most complex tasks in an IT ecosystem. Ease of use of secret management solutions is important, without which there will always be a conflict with the security best practices. As the IT industry expands and secrets diversify, it is becoming more challenging to secure the secrets while at rest and during transit. A secret may be a:

Password
API Credential
Certificates and associated key data
Symmetric Keys and others…

Few of the common challenges faced in secret management are:

Creation, storage, and transmission of secrets while tightly controlling access to them.
Key creation, storage and periodic rotation.
Certificate provisioning and deployment.

Azure Key Vault (KV) is a solution from Microsoft Azure which can be used to address many of the above mentioned challenges. In this article we shall look at an overview of the Azure KV, its management, associated roles, and secret management with best practices.

What is Azure Key Vault?

Typically secrets, passwords, certificates, API-tokens and keys are used all over in an IT ecosystem including source code, configuration files, digital formats and even on pieces of paper (sad but true ☹️).

An Azure KV is knitted with other Azure services and resources like SQL servers, Virtual Machines, Web Application, Storage Accounts etc. It is available on per-region basis, which means that a key vault must be deployed in the same Azure region where it is intended to be used with services and resources. To exemplify; an Azure KV must be available in the same region where an Azure virtual machine is deployed so that it can be used for storing Content Encryption Key (CEK) for Azure Disk Encryption.

Unlike other Azure resources, where the data is stored in general storage, an Azure KV is backed by a Hardware Security Module (HSM).

Azure Key Vault as seen in the Azure Portal

Azure Key Vault Access Model

Azure KV is logically divided into two interfaces called planes. These planes are :

Management Plane: This plane concerns with the Azure KV administration. This includes creation and deletion of the KV itself, access control to the key vault and setting key vault properties.
Data Plane: Keys, secrets and certificates are created, retrieved and deleted in data plane.

Both management and data plane use Azure Active Directory (Azure AD) for authentication . In the management plane, Role Based Access Control (RBAC) is used for authorization while the data plane uses the KV access policy for authorization.

Secret management in Azure Key Vault

An Azure KV enables developers, administrators, and auditors to manage, use and audit various types of secrets which include:

Keys
Secrets
Certificates
Storage account keys

1. Keys:

Cryptographic keys and algorithms for different operations are supported by the Azure KV. Keys are represented as JSON Web Key (JWK). Keys in Azure KV are classified into two types:

Soft Keys: These keys are processed by the software and are stored encrypted at rest using a key which is in a Hardware Security Module (HSM).
Hard Keys: These keys are managed and processed in an HSM.

An Azure KV supports hard and soft EC and RSA keys. These are represented as EC, EC-HSM, RSA and RSA-HSM key types (kty in JWK specification). Azure KV supports RSA keys of sizes 2048, 3096 and 4096 while EC keys of curve type P-256, P-384, P-521, and P-256K are supported. Once a key in Azure KV is created it can be used for the following cryptographic operations:

Sign and Verification: Keys can be used to sign the hashes. The onus is on the applications to create the hashes. The verification functionality is provided for convenience. For performance it is recommended to have signature verification at the application level.
Key Wrapping (Key Encryption): The Azure KV keys can be used as Key Encryption Key (KEK) to wrap (encrypt) other keys (symmetric keys). These symmetric keys are often referred to as Content Encryption Key(CEK) or Data Encryption Key (DEK).
Encryption and Decryption: The keys can also be used to encrypt payload. The maximum size of the payload is dependent on the key size and the encryption algorithm being used.

Azure KV keys also have attributes which are used in conjugation with the operations. These attributes include self explanatory created and updated attributes which are read-only. In addition to these two the other attributes are exp(expiration time), nbf (not before) and enabled. Key operations using a key can only be performed between the period specified by the nbf and exp attributes only if the key is enabled. Exception to nbf-exp window are the decrypt, unwrap and verify operations. These exceptions are there to facilitate two major use cases:

Test keys before not-before period for pre-production testing.
Recovery of data after the expiration time.

Above two use cases require the key to be in enabled state. Keys which are not in use must be disabled.

2. Secrets:

Azure KV accepts string as secret and stores them. There is no defined format as secret data in Azure KV is format agnostic. A secret in Azure KV can be an API key, credential, password, token symmetric key etc. The maximum size of a secret in Azure KV is 25000 bytes and is internally stored as a sequence of 8-bit.

An Azure Key Vault Secret as seen in the portal

Access to Azure KV secret is controlled at Key Vault level and is different from access control to other Key Vault components (keys, certificates, storage account keys) and has to be granted on per-principal basis.

Just like keys, secrets also have created, updated, nbf, exp and enabled attributes. Data stored in the secret can only be retrieved between the period specified by the nbf and exp attributes and only if the keys is enabled. A secret’s get(retrieve) operation can be performed outside the nbf-exp window to support pre-production testing and data recovery. It is recommended to disable the secrets not being used.

3. Certificates:

Azure KV allows certificate creation and import of X509 certificate. The certificates can be self-signed or Certification Authority (CA) issued. An Azure KV provides ways to manage the lifecycle of the certificate without interacting with the private key material associated with the certificate. The certificate owners can also define custom policies to manage the lifecycle of the certificate. The admins can also be notified on certificate lifecycle events like certificate creation, renewal and deletion.

A certificate policy is associated with every Azure KV. This policy determines how certificates will be created in the Azure KV and how their lifecycle will be managed.

Of all the objects within an Azure KV, certificates are definitely the most complex. They also have a very composite structure. When a KV certificate is created, along with it a key and secret objects are also created. The associated key is used for the key operations while the secret allows export of the certificate. The public X509 meta-data is stored within the certificate object. All three objects (certificate, key and secret) have the same name.

Certificates also have created, updated, exp, nbf, and enabled attributes. The exp and nbf attributes are associated with the X509 certificate and unlike key and secret objects are read-only. Certificate operations for enabled certificates can only be performed between the nbf-exp window and there is no exception to this.

4. Azure Storage Account Key Management:

Azure KV can also manage Azure Storage account keys. Every storage account has an associated account name and a password. The KV can be used to sync the storage account keys and rotate them. If a KV is delegated to manage storage account keys, the key never comes out of the KV. The permission model for the storage account keys object is very similar to the other KV objects which we have discussed above in this article.

Safeguarding Azure Key Vault

Before we start, let us take a look at two Azure KV attributes which play an important role in safeguarding Azure KV. These are:

enableSoftDelete: Setting this Azure KV parameter to true ensures that the KV and its associated objects remain recoverable for the next 90 days. During the 90 day window the KV can either be recovered or purged (permanently deleted). After the end of 90 days period, the KV is automatically deleted forever.
enablePurgeProtection: Turning on this KV parameter by setting its value to true makes sure that a KV can never be purged. This is used in conjugation with the enableSoftDelete attribute. As enableSoftDelete only ensures that the KV is recoverable 90 days post delete, turning on purge protection ensures that the key vault is not purged post delete. Once turned on, purge protection can not be turned-off.

When an Azure KV is provisioned both these features are disabled. Azure admins must make sure that these two features are turned on for all the KVs to protect them from any accidental or malicious deletion. There is no way to turn these two features on from the Azure portal. Azure CLI or Azure PoweShell can be used to enable them.

It is also recommended to turn on audit logging on the KVs so that all the activities on KV objects (keys, secrets, certificates and storage account keys) are logged and preserved.

Keys and secrets, at the time of their creation, don’t have a value associated with the exp attribute and hence they never expire. It is a strong recommendation to assign an expiry date to all the keys and secrets so that they can not be used beyond their lifetime.

Only authorized persons and applications must have access to key vault keys, secrets, certificates and storage account keys. Contributor role must also be controlled and periodically audited.