Azure Key Vault

Azure Key Vault is a cloud service that provides a secure, centralized repository for storing and controlling access to secrets, encryption keys, and certificates. In traditional on-premises environments, sensitive information like database connection strings, API keys, and SSL certificates is often stored in configuration files, source code, or even plain text spreadsheets. This approach is risky: if a developer checks a secret into a public repository, or if a server is compromised, attackers can easily steal these credentials. Key Vault solves this by removing the need for developers and applications to handle secrets directly. Instead, secrets are stored in a hardware security module (HSM)-backed vault, and applications retrieve them at runtime via authenticated and authorized calls. This centralization also enables auditing, rotation, and granular access control.

Key Vault offers two tiers:

Both tiers include operations (e.g., get, set) that are billed per 10,000 transactions. There is also a monthly fee per vault, with the first 1 million transactions per month free for Standard tier.

In an on-premises environment, secrets are often stored in configuration files, Windows Credential Manager, or a dedicated secrets management appliance (e.g., HashiCorp Vault). Key Vault provides a similar function but with Azure’s built-in high availability, automatic replication (within the region), and integration with other Azure services. On-premises solutions require manual setup of redundancy, backup, and hardware security modules. Key Vault also eliminates the need to manage the underlying infrastructure, patching, and scaling. However, if you have a strict requirement for on-premises secret storage, you can use Azure Key Vault Managed HSM (a standalone HSM) or hybrid scenarios with Azure Arc.

Azure Portal:

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

# Add a secret
az keyvault secret set --vault-name MyVault --name MySecret --value "MySecretValue"

# Retrieve a secret
az keyvault secret show --vault-name MyVault --name MySecret

PowerShell:

New-AzKeyVault -VaultName 'MyVault' -ResourceGroupName 'MyResourceGroup' -Location 'EastUS'
Set-AzKeyVaultSecret -VaultName 'MyVault' -Name 'MySecret' -SecretValue (ConvertTo-SecureString 'MySecretValue' -AsPlainText -Force)
Get-AzKeyVaultSecret -VaultName 'MyVault' -Name 'MySecret' -AsPlainText

ARM/Bicep Example:

resource vault 'Microsoft.KeyVault/vaults@2021-10-01' = {
  name: 'myVault'
  location: resourceGroup().location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    accessPolicies: []
    enableSoftDelete: true
    enablePurgeProtection: true
  }
}

Key Vault also integrates with Azure Policy to enforce compliance (e.g., require soft-delete).

Scenario 1: E-commerce Application with Database Credentials

A retail company runs an e-commerce application on Azure App Service that connects to an Azure SQL Database. Previously, the database connection string was stored in the appsettings.json file, which was checked into a private GitHub repository. A developer accidentally made the repo public for a few minutes, exposing the credentials. To fix this, the team moves the connection string to Azure Key Vault. They enable a system-assigned managed identity on the App Service and grant it 'Get' and 'List' permissions on the vault. The application code is updated to use DefaultAzureCredential and SecretClient to retrieve the connection string at startup. The vault is configured with soft-delete and purge protection. The team also sets up a log analytics workspace to monitor access. Now, even if the source code is exposed, the actual credentials remain secure. The operations team can rotate the database password without redeploying the app—they just update the secret in Key Vault, and the app fetches the new value on the next restart. Cost is minimal: the Standard tier vault costs a few dollars per month plus transaction fees.

Scenario 2: Certificate Management for HTTPS

A financial services company needs to secure multiple web applications with SSL/TLS certificates. They previously purchased certificates from a third-party CA and manually installed them on each VM, which was error-prone and led to expired certificates causing outages. They migrate to Azure Key Vault for certificate management. They create a Premium tier vault to store the certificate (which includes a private key) and use the vault's auto-renewal feature with a trusted CA. The web applications are configured to pull the certificate from the vault using the Key Vault certificate binding in Azure App Service or Application Gateway. The vault logs all certificate operations, and alerts are set for upcoming expiration. The company saves time and avoids outages. The Premium tier is necessary because the certificate's private key must be HSM-protected per compliance requirements.

Scenario 3: Encryption Key Management for Azure Storage

A healthcare organization stores sensitive patient data in Azure Blob Storage. They are required to use customer-managed encryption keys for compliance. They create a Key Vault (Premium tier) and generate an RSA key. They then configure the storage account to use the key from Key Vault for encryption (Azure Storage Service Encryption with customer-managed keys). The storage account accesses the key via a managed identity. The organization can rotate the key manually or set up automated rotation. If the key is disabled or deleted, the storage account becomes inaccessible, providing a kill-switch capability. This setup ensures that even Microsoft cannot access the encrypted data without the key. The cost includes the vault fee and per-operation charges for key wrap/unwrap operations.

Common Pitfalls: When Key Vault is misconfigured (e.g., access policies too permissive, soft-delete disabled), secrets can be exposed or permanently lost. For example, if a vault is deleted without soft-delete, all secrets are gone forever. If RBAC is used but the wrong role is assigned (e.g., 'Owner' instead of 'Key Vault Secrets User'), a user might have unintended write access. Always follow the principle of least privilege.