Azure Key Vault Basics

Azure Key Vault is a cloud service that provides secure storage and management of sensitive information such as passwords, connection strings, API keys, encryption keys, and certificates. It helps organizations safeguard cryptographic keys and secrets used by cloud applications and services. Key Vault is part of Microsoft's security and compliance offerings and is designed to meet stringent compliance standards like FIPS 140-2 Level 2 (for hardware security modules) and SOC.

Key Vault eliminates the need for developers to store secrets in code or configuration files, which is a common security risk. Instead, applications can retrieve secrets at runtime from Key Vault using secure authentication methods like managed identities.

Azure Key Vault is built on top of Azure's infrastructure and uses hardware security modules (HSMs) for key protection. When you create a Key Vault, it is associated with an Azure subscription and an Azure AD tenant. The vault itself is a logical container with a unique DNS name (e.g., myvault.vault.azure.net).

Authentication to Key Vault happens via Azure Active Directory. There are two authentication models: - Access policies (legacy): You assign permissions to individual users, groups, or service principals at the vault level. Each vault has its own access policy. - Azure RBAC (recommended): Using the built-in roles like Key Vault Secrets User, Key Vault Crypto Officer, etc., you manage permissions at the vault scope using Azure role-based access control. This is the modern approach and is required for some features like managed HSM.

Once authenticated, operations on secrets, keys, and certificates are performed via REST API calls. For example, to get a secret, an application sends a GET request to https://myvault.vault.azure.net/secrets/MySecret?api-version=7.4. The Key Vault service checks the caller's permissions (via the access policy or RBAC), and if allowed, returns the secret value. All operations are logged to Azure Monitor and can be streamed to Log Analytics, Event Hubs, or Storage.

Using Azure CLI:

# Create a resource group
az group create --name MyResourceGroup --location eastus

# Create a Key Vault
az keyvault create --name MyVault --resource-group MyResourceGroup --location eastus --sku standard

# Add a secret
az keyvault secret set --vault-name MyVault --name MySecret --value "P@ssw0rd!"

# Retrieve a secret
az keyvault secret show --vault-name MyVault --name MySecret --query value -o tsv

# Enable soft-delete and purge protection
az keyvault update --name MyVault --resource-group MyResourceGroup --enable-soft-delete true --enable-purge-protection true

Using PowerShell:

New-AzKeyVault -VaultName 'MyVault' -ResourceGroupName 'MyResourceGroup' -Location 'eastus' -Sku 'Standard'
Set-AzKeyVaultSecret -VaultName 'MyVault' -Name 'MySecret' -SecretValue (ConvertTo-SecureString 'P@ssw0rd!' -AsPlainText -Force)
Get-AzKeyVaultSecret -VaultName 'MyVault' -Name 'MySecret' -AsPlainText

Verification: Check access policies, soft-delete status, and diagnostic settings.

az keyvault show --name MyVault --query "properties"
az keyvault list-deleted

On the exam, you might be asked which method to use for granting access. Remember: RBAC is the recommended approach for new deployments. Access policies are legacy but still supported. The exam may test that RBAC is required for certain features like managed HSM.

The default retention period is 90 days, but it can be set between 7 and 90 days. The exam may ask what the default is.

By default, Key Vault allows access from all networks. You must explicitly disable public access and configure firewall rules. The exam may present a scenario where an application cannot access Key Vault because network restrictions are too strict.

If an application receives HTTP 429 errors, it means it is exceeding the operation limit. The solution is to implement retry logic with exponential backoff, not to increase the limit (which is not configurable).

A large e-commerce company runs hundreds of microservices on Azure Kubernetes Service (AKS). Each service needs database connection strings, API keys, and service-to-service authentication tokens. Previously, developers stored secrets in environment variables or config files, leading to security incidents when secrets were exposed in logs or source code. The company deployed Azure Key Vault as a central secrets store. They created one Key Vault per environment (dev, test, prod) in the same region as the AKS cluster. They used Azure AD pod-managed identities (now replaced by Workload Identity) to allow each pod to authenticate to Key Vault without storing any credentials. They assigned RBAC roles at the vault scope: each service got a custom role with only the permissions it needed (e.g., 'Secrets Get' for its own secrets). They enabled soft-delete with a 90-day retention and purge protection to prevent accidental deletion. Diagnostic logs were sent to a central Log Analytics workspace for auditing. The result: secrets are never in code, access is granular, and all access is logged. One challenge was throttling: during peak traffic, some services exceeded the default 10,000 GET operations per second per vault. They solved this by implementing caching with a 5-minute TTL and adding retry logic with exponential backoff. They also considered using multiple vaults to distribute load.

A financial services company must comply with regulatory requirements that mandate customer-managed keys for encryption at rest. They use Azure Storage for sensitive data. They created a Key Vault in the same region as the storage account, using the Premium tier to ensure HSM-backed keys (FIPS 140-2 Level 2). They generated a new RSA key (4096-bit) in the vault. Then, when creating the storage account, they selected 'Customer-managed keys' and pointed to the Key Vault and key. The storage account now uses that key for envelope encryption. The company also enabled soft-delete and purge protection on the vault to prevent accidental key deletion, which would render the storage account inaccessible. They set up alerts for key operations (e.g., key disable, key deletion) using Azure Monitor. A common misconfiguration: if the storage account's managed identity does not have 'Get', 'Wrap Key', and 'Unwrap Key' permissions on the key, encryption will fail. They used RBAC to assign the 'Key Vault Crypto Service Encryption User' role to the storage account's system-assigned managed identity. They also tested key rotation by creating a new key version and updating the storage account to use the new version – this required manual intervention via Azure CLI because automatic rotation is not supported for storage encryption keys.

A SaaS company manages hundreds of custom domains for its multi-tenant web application. They use Azure Key Vault to store and automatically renew TLS certificates. They import certificates from a public CA (e.g., DigiCert) into Key Vault, or generate self-signed certificates for internal use. They then configure Azure Front Door or Application Gateway to reference the certificate stored in Key Vault. This allows centralized certificate management: when a certificate expires, they only need to update it in Key Vault, and the front-end service automatically picks up the new version (with a short propagation delay). They enabled auto-rotation for certificates that support it (e.g., DigiCert). For domains that require manual validation, they set up alerts 30 days before expiration. A common issue: the service principal for Front Door must have 'Get' and 'List' permissions on the certificate secret. If these are missing, the certificate cannot be retrieved. They used RBAC with the 'Key Vault Secrets User' role. They also had to ensure the certificate is exported as a PFX with the private key included. If the private key is not marked as exportable, Key Vault cannot use it for TLS termination.