Azure Key Vault

Owned by Roger Cruz
Last updated: Feb 10, 2022
16 min read

Intro

Azure Key Vault is a centralized cloud service for storing application secrets such as encryption keys, certificates, and server-side tokens.

 

Documentation

Tips and Tidbits

 

  • Each key vault is a collection of cryptographic keys and cryptographically protected data (call them “secrets”) managed by one or more responsible individuals within your organization.

  • Key vaults also control and log the access to anything stored in them.

  • Vault names need to be globally unique due to their access via REST API URLs.  The names are restricted to 3-24 alphanumeric characters, including dash.

  • Secret names can't exceed 127 characters in length and must only use alphanumeric characters, including dashes.

  • The actual secret value can have any UTF-8 characters and not exceed 25 KB in size.

  • Each secret is assigned a URL which can be used to obtain its value with HTTP GET operations.

  • Access to a key vault can be controlled based on specific actions, such as GET (to read the vault), LIST (to list all secret names in the vault) and SET (to create the secret entry). 

  • Applications can be granted these access rights through Azure AD via a token-granting REST API specifically created for the app.

  • When "Managed Identities" is enabled, Azure's App Service inserts a secret into the applications' environment so it can access the token-granting REST API.

  • Azure Resource Manager can securely deploy certificates stored in Azure Key Vault to Azure VMs when the VMs are deployed. 

  • Azure Disk Encryption requires that your key vault and VMs reside in the same Azure region and subscription.

  • URL uses the format https://{key vault}.vault.azure.net/secrets/{secret name} to retrieve a secret from the vault.

  • You can use secrets to securely store tokens, passwords, API keys, database connection strings, and other secrets.

  • Azure Key Vault does not allow you to move a key vault from one region to another.

    • You can, however, create a key vault in the new region, manually copy each individual key, secret, or certificate from your existing key vault to the new key vault, and then remove the original key vault.

  • A web app and a key vault do not need to be in the same region.

Keys

  • A key is a cryptographic asset destined for a particular use such as the asymmetric master key of Microsoft Azure RMS, or the asymmetric keys used for SQL Server TDE

  • Microsoft and your apps don't have access to the stored keys directly once a key is created or added to a key vault.

    • Applications must use your keys by calling cryptography methods on the Key Vault service.

    • The Key Vault service performs the requested operation within its hardened boundary. T

    • he application never has direct access to the keys.

  • Keys can be single instanced (only one key exists) or be versioned.

    • In the versioned case, a key is an object with a primary (active) key and a collection of one or more secondary (archived) keys created when keys are rolled (renewed).

 

Key Vault Best Practices

  • Discover Azure Key Vault best practices

  • Use separate key vaults: Recommended to use a vault per application per environment (Development, Pre-Production and Production).

  • Control access to your vault: allow only authorized applications and users

  • Backup: Create regular back ups of your vault on update/delete/create of objects within a Vault.

  • Logging: Be sure to turn on logging and alerts.

  • Recovery options: Turn on soft-delete and purge protection if you want to guard against force deletion of the secret.

 

Hardware protected keys

  • The Key Vault service supports using HSMs that provide a hardened, tamper-resistant environment for cryptographic processing and key generation.

  • Azure has dedicated HSMs validated to FIPS 140-2 Level 2 that Key Vault uses to generate or store keys.

  • These HSM-backed keys are always locked to the boundary of the HSM.

    • When you ask the Key Vault service to decrypt or sign with a key, the operation is performed inside an HSM.

  • You can import or generate a key in a hardware security module (HSM); the key will never leave the HSM boundary

Bring Your Own Keys (BYOK)

  • Bring your own key specification

  • Requires Key Vault Premium!

  • In Key Vault, generate a key (referred to as a Key Exchange Key (KEK)).

    • The KEK is used to encrypt the key you want to import (the target key).

    • The KEK must be an RSA-HSM key that has only the import key operation.

    • Only Key Vault Premium SKU supports RSA-HSM keys.

  • Download the KEK public key as a .pem file.

  • Transfer the KEK public key to an offline computer that is connected to an on-premises HSM.

  • In the offline computer, use the BYOK tool provided by your HSM vendor to create a BYOK file.

  • The target key is encrypted with a KEK, which stays encrypted until it is transferred to the Key Vault HSM.

    • Only the encrypted version of your key leaves the on-premises HSM.

  • A KEK that's generated inside a Key Vault HSM is not exportable. HSMs enforce the rule that no clear version of a KEK exists outside a Key Vault HSM.

  • The KEK must be in the same key vault where the target key will be imported.

  • When the BYOK file is uploaded to Key Vault, a Key Vault HSM uses the KEK private key to decrypt the target key material and import it as an HSM key.

    • This operation happens entirely inside a Key Vault HSM.

    • The target key always remains in the HSM protection boundary.

 

Software protected keys

  • Key Vault can also generate and protect keys using software-based RSA and ECC algorithms.

  • In general, software-protected keys offer most of the features as HSM-protected keys except the FIPS 140-2 Level 2 assurance

 

Azure Key Vault throttling guidance

  • Azure Key Vault throttling guidance

  • Service limits in Key Vault prevent misuse of resources and ensure quality of service for all of Key Vault's clients.

  • When a service threshold is exceeded, Key Vault limits any further requests from that client for a period of time, returns HTTP status code 429 (Too many requests), and the request fails.

    • Failed requests that return a 429 do not count towards the throttle limits tracked by Key Vault.

  • If an overwhelming number of requests occurs, throttling your client's requests helps maintain optimal performance and reliability of the AKV service.

  • Best practices for maximizing your throughput:

    • Ensure you have throttling in place. Client must honor exponential back-off policies for 429's and ensure you are doing retries as per the guidance below

    • Divide your Key Vault traffic amongst multiple vaults and different regions.

      • Use a separate vault for each security/availability domain.

      • If you have five apps, each in two regions, then we recommend 10 vaults each containing the secrets unique to app and region.

    • Cache the secrets you retrieve from Azure Key Vault in memory, and reuse from memory whenever possible

    • If your app comprises multiple nodes that need to read the same secret(s), then consider using a fan out pattern, where one entity reads the secret from Key Vault, and fans out to all nodes.

      • Cache the retrieved secrets only in memory.

  • A subscription-wide limit for all transaction types is five times the individual key vault limit

Key Vault Redundancy

  • Azure Key Vault availability and redundancy

  • The contents of your key vault are replicated within the region and to a secondary region at least 150 miles away, but within the same geography to maintain high durability of your keys and secrets

  • In the rare event that an entire Azure region is unavailable, the requests that you make of Azure Key Vault in that region are automatically routed (failed over) to a secondary region

  • During failover, your key vault is in read-only mode.

 

Key Vault Backup

  • Azure Key Vault backup and restore

  • Key Vault doesn't currently provide a way to back up an entire key vault in a single operation.

  • A backup creates a point-in-time snapshot. Secrets might renew during a backup, causing a mismatch of encryption keys.

  • When you back up a key vault object, such as a secret, key, or certificate, the backup operation will download the object as an encrypted blob.

    • This blob can't be decrypted outside of Azure.

    • To get usable data from this blob, you must restore the blob into a key vault within the same Azure subscription and Azure geography

      • US and Mexico are two different geographies so you won’t be abl to move key vault secrets this way.

      • However, you can export certificates and manually import them into a vault in another geography.

Key Vault Access

 

 

 

  • Discover Azure Key Vault best practices

  • Authenticate to Azure Key Vault

  • To do any operations with Key Vault, you first need to authenticate to it. There are three ways to authenticate to Key Vault:

  • Managed identities for Azure resources: you can assign an identity to your virtual machine that has access to Key Vault.

    • The benefit of this approach is that the app or service isn't managing the rotation of the first secret. Azure automatically rotates the service principal client secret associated with the identity.

    • We recommend this approach as a best practice.

  • Service principal and certificate: You can use a service principal and an associated certificate that has access to Key Vault.

    • We don't recommend this approach because the application owner or developer must rotate the certificate.

  • Service principal and secret: Although you can use a service principal and a secret to authenticate to Key Vault, we don't recommend it.

    • It's hard to automatically rotate the bootstrap secret that's used to authenticate to Key Vault.

  • There are two ways to obtain a service principal:

    • Enable a system-assigned managed identity for the application.

    • register the application with your Azure AD tenant.

  • Perfect Forward Secrecy (PFS) protects connections between customers’ client systems and Microsoft cloud services by unique keys.

    • Connections also use RSA-based 2,048-bit encryption key lengths.

Soft Delete And Purge Protection

  • Azure Key Vault soft-delete overview

  • Soft-delete will be enabled on all key vaults

  • Key Vault's soft-delete feature allows recovery of the deleted vaults and deleted key vault objects (for example, keys, secrets, certificates)

  • Once a secret, key, certificate, or key vault is deleted, it will remain recoverable for a configurable period of 7 to 90 calendar days.

    • If no configuration is specified the default recovery period will be set to 90 days.

  • Two operations must be made to permanently delete a secret.

    • First a user must delete the object, which puts it into the soft-deleted state.

    • Second, a user must purge the object in the soft-deleted state.

      • The purge operation requires additional access policy permissions. 

  • To purge a secret in the soft-deleted state, a service principal must be granted an additional "purge" access policy permission.

    • The purge access policy permission is not granted by default to any service principal including key vault and subscription owners and must be deliberately set.

  • When purge protection is on, a vault or an object in the deleted state cannot be purged until the retention period has passed.

    • Soft-deleted vaults and objects can still be recovered, ensuring that the retention policy will be followed.

  • When creating a new key vault, soft-delete is on by default.

    • Once soft-delete is enabled on a key vault it cannot be disabled. The same for purge protection.

    • Once set, the retention policy interval cannot be changed.

  • When purge protection is on, a vault or an object in the deleted state cannot be purged until the retention period has passed

  • Upon deleting a key vault, the service creates a proxy resource under the subscription, adding sufficient metadata for recovery.

  • The proxy resource is a stored object, available in the same location as the deleted key vault.

 

 

When a Key Vault is soft-deleted, services that are integrated with the Key Vault will be deleted. For example: Azure RBAC roles assignments and Event Grid subscriptions. Recovering a soft-deleted Key Vault will not restore these services. They will need to be recreated.

Certificates

 

Integrating Key Vault with DigiCert certificate authority

  • Azure Key Vault users can generate DigiCert certificates directly from their key vaults: Integrating Key Vault with DigiCert certificate authority

  • Make sure you have the following information from your DigiCert CertCentral account:

    • CertCentral account ID

    • Organization ID

    • API key

  • you can then add DigiCert to the certificate authority list in the key vault.

Creating a certificate with a CA partnered with Key Vault

Applications can request a certificate: https://docs.microsoft.com/en-us/azure/key-vault/certificates/certificate-scenarios#creating-a-certificate-with-a-ca-partnered-with-key-vault

(1) - In the diagram above, your application is creating a certificate which internally begins by creating a key in your key vault.
(2) - Key Vault sends an TLS/SSL Certificate Request to the CA.
(3) - Your application polls, in a loop and wait process, for your Key Vault for certificate completion. The certificate creation is complete when Key Vault receives the CA’s response with x509 certificate.
(4) - The CA responds to Key Vault's TLS/SSL Certificate Request with an X509 TLS/SSL Certificate.
(5) - Your new certificate creation completes with the merger of the X509 Certificate for the CA.

 

All az cli commands for dealing with certificates: az keyvault certificate


Certificate creation methods

 When a KV certificate is created the private key is created inside the key vault and never exposed to certificate owner

  • Create a self-signed certificate: This will create a public-private key pair and associate it with a certificate. The certificate will be signed by its own key.

You can create a self-signed certificate in this tutorial: Quickstart: Set and retrieve a certificate from Azure Key Vault using Azure CLI

 

  • Create a new certificate manually: This will create a public-private key pair and generate an X.509 certificate signing request. The signing request can be signed by your registration authority or certification authority. The signed x509 certificate can be merged with the pending key pair to complete the KV certificate in Key Vault.

 

  • When a KV certificate is created for the first time, an addressable key and secret is also created with the same name as that of the certificate.

 

This tutorial has really good info on how to Create Azure Key Vault Certificates using 3rd Party Certificate Authorities

 

Pricing

 

See more here: https://azure.microsoft.com/en-us/pricing/details/key-vault/

 

Use Key Vault references for App Service and Azure Functions

Azure Key Vault REST API reference

  • Azure Key Vault REST API reference

  • Get Secret - Get Secret

    • Get a specified secret from a given key vault.

    • The GET operation is applicable to any secret stored in Azure Key Vault. This operation requires the secrets/get permission.

    • GET {vaultBaseUrl}/secrets/{secret-name}/{secret-version}?api-version=7.2

 

Code Samples

Creating Vault With Azure CLI

az keyvault create --name <globally unique vault name> --resource-group <resource group ID>



JSON Returned Data
az keyvault create --name rogertesting --resource-group ca022f9f-a2c9-47a5-a7f5-934b9ac315a2 { "id": "\/subscriptions\/04923703-3eee-4faa-aa54-1f27e2749c05\/resourceGroups\/ca022f9f-a2c9-47a5-a7f5-934b9ac315a2\/providers\/Microsoft.KeyVault\/vaults\/rogertesting", "location": "southcentralus", "name": "rogertesting", "properties": { "accessPolicies": [ { "applicationId": null, "objectId": "fe3a3cb8-e500-4768-bfcd-66899289c47f", "permissions": { "certificates": [ "get", "list", "delete", "create", "import", "update", "managecontacts", "getissuers", "listissuers", "setissuers", "deleteissuers", "manageissuers", "recover" ], "keys": [ "get", "create", "delete", "list", "update", "import", "backup", "restore", "recover" ], "secrets": [ "get", "list", "set", "delete", "backup", "restore", "recover" ], "storage": [ "get", "list", "delete", "set", "update", "regeneratekey", "setsas", "listsas", "getsas", "deletesas" ] }, "tenantId": "604c1504-c6a3-4080-81aa-b33091104187" } ], "createMode": null, "enablePurgeProtection": null, "enableSoftDelete": null, "enabledForDeployment": false, "enabledForDiskEncryption": null, "enabledForTemplateDeployment": null, "networkAcls": null, "provisioningState": "Succeeded", "sku": { "name": "standard" }, "tenantId": "604c1504-c6a3-4080-81aa-b33091104187", "vaultUri": "https:\/\/rogertesting.vault.azure.net\/" }, "resourceGroup": "ca022f9f-a2c9-47a5-a7f5-934b9ac315a2", "tags": { }, "type": "Microsoft.KeyVault\/vaults" }



Secret Creation using Azure AZ CLI

Create Secret Value Pair In Vault
JSRON Returned Value



Programming - Using .NET

  • Azure Key Vault developer's guide

  • NuGet package:  Microsoft.Azure.KeyVault.

  • Class: KeyVaultClient

  • Method: AddAzureKeyVault (Requires GET and LIST permissions)

  • Key Vault SDK is using Azure Identity client library, which allows seamless authentication to Key Vault

Look here: Access secrets stored in Azure Key Vault for the actual code to create a Web app that accesses the vault

Create A Web App Template

 

  • When an access token is not supplied, or when a token is not accepted by the service, an HTTP 401 error will be returned to the client and will include the WWW-Authenticate header

  • The parameters on the WWW-Authenticate header are:

    • authorization: The address of the OAuth2 authorization service that may be used to obtain an access token for the request.

    • resource: The name of the resource (https://vault.azure.net) to use in the authorization request.

  • Exercise: Set and retrieve a secret from Azure Key Vault by using Azure CLI

Quickstart: Azure Key Vault secret client library for .NET