Microsoft Azure — Azure Key Vault

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers azure key vault with production-ready configurations, best practices, and hands-on examples.

Why Azure Key Vault Exists

Secrets management is the most neglected part of DevOps. Developers hardcode connection strings, API keys, and certificates into config files, environment variables, or worse, source control. Azure Key Vault solves this by providing a centralized, hardware-backed store for secrets, keys, and certificates. It integrates with Azure services like App Service, Functions, and VMs, and supports access policies and RBAC. The vault itself is protected by Azure AD and can be firewalled to specific VNets. If you're not using a vault, you're one git push away from a breach.

az keyvault create \
  --name myprodvault \
  --resource-group prod-rg \
  --location eastus \
  --sku premium \
  --enable-purge-protection true

Vault Access Control: Policies vs RBAC

Azure Key Vault offers two authorization models: access policies and RBAC. Access policies are vault-specific and grant permissions to users, groups, or service principals. RBAC uses Azure Resource Manager roles like 'Key Vault Secrets User' and 'Key Vault Crypto Officer'. For production, prefer RBAC because it integrates with Azure AD Privileged Identity Management (PIM) and allows just-in-time access. Access policies are simpler for small teams but become unmanageable at scale. Never assign permissions to individuals; always use groups or managed identities.

az role assignment create \
  --assignee-object-id $(az ad sp show --id <managed-identity-id> --query id -o tsv) \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/.../resourceGroups/prod-rg/providers/Microsoft.KeyVault/vaults/myprodvault

Storing and Retrieving Secrets

Secrets are encrypted at rest using AES-256. To store a secret, use the Azure CLI or SDK. Retrieval should happen at runtime, not at deploy time. Never cache secrets in memory longer than necessary. Use the Key Vault SDK's caching mechanism with a short TTL (e.g., 5 minutes) to reduce API calls. For high-throughput scenarios, consider using Azure App Configuration as a cache layer. Always handle KeyVaultErrorException and implement retry logic with exponential backoff.

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

var client = new SecretClient(
    new Uri("https://myprodvault.vault.azure.net"),
    new DefaultAzureCredential());

// Store a secret
await client.SetSecretAsync("DbConnectionString", "Server=...;Database=...;User Id=...;Password=...;");

// Retrieve a secret
KeyVaultSecret secret = await client.GetSecretAsync("DbConnectionString");
string connectionString = secret.Value;

// Use connection string...
// Clear sensitive data
connectionString = null;

Managed Identities: The Zero-Secret Pattern

Managed identities eliminate the need for credentials in your code. An Azure resource (VM, App Service, Function) gets an identity in Azure AD. Your code authenticates to Key Vault using that identity via DefaultAzureCredential. No client secrets, no certificates to rotate. System-assigned identities are tied to the resource lifecycle; user-assigned identities are independent and can be shared. For production, prefer user-assigned identities when you need the same identity across multiple resources.

# Enable system-assigned managed identity on an App Service
az webapp identity assign \
  --name myapp \
  --resource-group prod-rg

# Grant access to Key Vault
az role assignment create \
  --assignee-object-id $(az webapp identity show --name myapp --resource-group prod-rg --query principalId -o tsv) \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/.../resourceGroups/prod-rg/providers/Microsoft.KeyVault/vaults/myprodvault

Key Rotation and Versioning

Key Vault supports automatic key rotation for RSA and EC keys. For secrets, you must implement rotation yourself. Use Key Vault's event grid integration to trigger a function on secret expiry. Store multiple versions of a secret; applications should reference the latest version by omitting the version identifier. For database credentials, use a pattern where the app retries on failure, fetching the latest secret. Never hardcode a secret version — that defeats rotation.

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
using System;

public static async Task RotateSecret(TimerInfo myTimer, ILogger log)
{
    var client = new SecretClient(
        new Uri(Environment.GetEnvironmentVariable("VAULT_URL")),
        new DefaultAzureCredential());

    // Generate new password
    string newPassword = GenerateSecurePassword();

    // Set new version (Key Vault automatically versions)
    await client.SetSecretAsync("DbPassword", newPassword);

    log.LogInformation("Secret rotated at {Time}", DateTime.UtcNow);
}

private static string GenerateSecurePassword()
{
    const string chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*()";
    var random = new Random();
    return new string(Enumerable.Repeat(chars, 32)
        .Select(s => s[random.Next(s.Length)]).ToArray());
}

Soft-Delete and Purge Protection

Soft-delete allows recovery of deleted vaults and secrets within a retention period (default 90 days). Purge protection prevents permanent deletion until the retention period ends. Without these, a single accidental deletion can cause an outage. Enable both on all production vaults. To recover a deleted vault, use az keyvault recover. To list deleted vaults, use az keyvault list-deleted. Test your recovery process regularly.

# List deleted vaults
az keyvault list-deleted --query "[].{Name:name, DeletionDate:properties.deletionDate}" -o table

# Recover a deleted vault
az keyvault recover --name myprodvault --resource-group prod-rg

# Check recovery status
az keyvault show --name myprodvault --resource-group prod-rg --query properties.vaultUri

Monitoring and Auditing with Diagnostic Logs

Key Vault logs all read, write, and delete operations via Azure Monitor. Enable diagnostic settings to send logs to Log Analytics, Storage, or Event Hubs. Use KQL queries to detect anomalies like a sudden spike in secret reads or access from unexpected IPs. Set up alerts for critical operations like secret deletion or vault configuration changes. For compliance, retain logs for at least 1 year. Integrate with Azure Sentinel for advanced threat detection.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName == "SecretGet"
| summarize Count = count() by CallerIPAddress, bin(TimeGenerated, 1h)
| where Count > 100
| project TimeGenerated, CallerIPAddress, Count
| order by Count desc

Network Security: Firewalls and Private Endpoints

By default, Key Vault accepts traffic from all networks. For production, restrict access using firewall rules and service endpoints or private endpoints. Firewall rules allow you to whitelist specific IP ranges. Private endpoints give the vault a private IP in your VNet, eliminating exposure to the public internet. Use service endpoints for simpler setups, but private endpoints are more secure. Combine with network security groups (NSGs) for defense in depth.

# Create a private endpoint for Key Vault
az network private-endpoint create \
  --name kv-private-endpoint \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --subnet private-subnet \
  --private-connection-resource-id /subscriptions/.../resourceGroups/prod-rg/providers/Microsoft.KeyVault/vaults/myprodvault \
  --group-id vault \
  --connection-name kv-connection

# Disable public network access
az keyvault update \
  --name myprodvault \
  --default-action Deny \
  --bypass AzureServices

Backup and Disaster Recovery

Key Vault does not replicate secrets across regions automatically. For disaster recovery, export secrets using az keyvault secret backup and store the backup in a secure, geo-redundant location like Azure Storage with GRS. Alternatively, use Azure Site Recovery or a secondary vault in another region with manual sync. Test your DR plan by restoring a backup to a new vault. Remember that backup files are encrypted at rest with the vault's key — you need the same Azure subscription to restore.

# Backup all secrets
for secret in $(az keyvault secret list --vault-name myprodvault --query "[].id" -o tsv); do
  name=$(basename $secret)
  az keyvault secret backup --vault-name myprodvault --name $name --file "${name}.backup"
done

# Restore to a secondary vault
az keyvault secret restore --vault-name myprodvault-dr --file "DbConnectionString.backup"

Cost Management and Scaling

Key Vault pricing is based on operations (reads, writes, etc.) and key storage. Standard tier costs ~$0.03 per 10,000 operations; Premium adds HSM-backed keys. For high-throughput apps, batch secret retrievals or use caching to reduce costs. Monitor operation counts in Azure Cost Management. Consider using Azure App Configuration for non-secret configuration to reduce Key Vault calls. Scale by creating multiple vaults for different environments or teams to isolate blast radius.

# Get Key Vault operation count for the last 30 days
az monitor metrics list \
  --resource /subscriptions/.../resourceGroups/prod-rg/providers/Microsoft.KeyVault/vaults/myprodvault \
  --metric ServiceApiResult \
  --interval PT1H \
  --aggregation Count \
  --query "value[?name.value=='ServiceApiResult'].timeseries[].data[].total" -o tsv | awk '{sum+=$1} END {print sum}'

Common Pitfalls and Anti-Patterns

Hardcoding secret names in application code is an anti-pattern — use configuration files or environment variables to specify secret names. Another mistake is storing large secrets (>25KB) — Key Vault has a size limit. Use Azure Storage for blobs and store the URL in Key Vault. Never log secret values. Avoid using the same vault for production and non-production — use separate vaults per environment. Finally, don't ignore Key Vault service limits: 10,000 secrets per vault, 2,000 operations per second per vault.

// ANTI-PATTERN: Hardcoding secret name
string secretName = "ProdDbPassword"; // BAD: should come from config

// ANTI-PATTERN: Logging secret
Console.WriteLine($"Secret value: {secret.Value}"); // BAD: never log secrets

// ANTI-PATTERN: Storing large data
await client.SetSecretAsync("LargeFile", base64EncodedFile); // BAD: >25KB will fail

Production Checklist for Key Vault

Before going live, verify: (1) Soft-delete and purge protection enabled. (2) RBAC with managed identities, not access policies. (3) Firewall rules or private endpoints configured. (4) Diagnostic logs streaming to Log Analytics. (5) Alerts set for secret deletion and unusual access patterns. (6) Backup strategy in place for DR. (7) Rotation automation for secrets. (8) Caching implemented in application code. (9) Separate vaults per environment. (10) Regular security reviews of vault permissions.

# Check soft-delete and purge protection
az keyvault show --name myprodvault --query "properties.{softDelete:enableSoftDelete, purgeProtection:enablePurgeProtection}"

# Check diagnostic settings
az monitor diagnostic-settings list --resource /subscriptions/.../resourceGroups/prod-rg/providers/Microsoft.KeyVault/vaults/myprodvault

# Check RBAC assignments
az role assignment list --scope /subscriptions/.../resourceGroups/prod-rg/providers/Microsoft.KeyVault/vaults/myprodvault --query "[].{role:roleDefinitionName, principal:principalName}"