Azure Key Vault

Every application uses secrets — database connection strings, API keys, passwords, and encryption keys. Storing these secrets in application code, configuration files, or environment variables is a serious security risk. Azure Key Vault is a dedicated, highly secure cloud service for storing, managing, and accessing secrets, encryption keys, and certificates — keeping them completely separate from application code.

Why Key Vault?

A common developer mistake is placing database passwords or API keys directly inside code files and checking them into source control. This means anyone with code access also has access to production credentials — a major security breach waiting to happen. Key Vault solves this by storing all sensitive values in a secure vault and letting applications retrieve them at runtime using their identity — no hardcoded secrets anywhere.

Without Key Vault vs With Key Vault

  WITHOUT Key Vault (Insecure):
  ┌─────────────────────────────────┐
  │ app.config / environment var    │
  │ DB_PASSWORD = "MyP@ssw0rd123"   │ ← Visible in code, config, and logs!
  │ API_KEY = "sk-abc123xyz789"     │
  └─────────────────────────────────┘

  WITH Key Vault (Secure):
  ┌─────────────────────────────────┐     ┌──────────────────────────┐
  │ Application Code                │     │  Azure Key Vault         │
  │                                 │────►│  Secret: DB_PASSWORD     │
  │ // No secrets here!             │◄────│  Secret: API_KEY         │
  │ password = vault.getSecret(...) │     │  Key: EncryptionKey      │
  └─────────────────────────────────┘     │  Cert: SSL Certificate   │
                                          └──────────────────────────┘
  Application retrieves secrets at runtime using its Managed Identity.
  Secrets never appear in code, config files, or version control.

What Key Vault Stores

Azure Key Vault manages three types of sensitive objects:

Secrets

Any string value that needs to be protected. Secrets are versioned — each time a secret is updated, a new version is created, and previous versions remain accessible. This enables secret rotation without breaking applications that reference older versions.

• Database passwords and connection strings
• API keys and access tokens
• Storage account keys
• Application passwords

Keys (Cryptographic Keys)

RSA and EC cryptographic keys used for encryption, decryption, and signing operations. The private key material never leaves Key Vault — applications send data to Key Vault to be encrypted/decrypted, and Key Vault performs the operation internally. This protects the key from ever being exposed.

• Customer-managed keys (CMK) for encrypting Azure Storage, SQL, and other services
• Document signing keys
• TLS/SSL private keys

Certificates

X.509 certificates for HTTPS/TLS, code signing, and authentication. Key Vault can create, import, store, and automatically renew certificates. It integrates with certificate authorities like DigiCert and GlobalSign to handle the full certificate lifecycle automatically.

Key Vault Tiers

Accessing Key Vault Securely – Managed Identity

The most secure way for an application to access Key Vault is through a Managed Identity. A Managed Identity is an automatic Azure AD identity assigned to an Azure resource (VM, App Service, Function, etc.). The identity has no password or secret to manage — Azure handles credential rotation automatically. The application uses this identity to authenticate to Key Vault and retrieve secrets.

Step-by-Step: App Service Reading a Secret from Key Vault

  Step 1: Enable System-Assigned Managed Identity on App Service
          (App Service → Identity → System assigned → ON)

  Step 2: Grant the App Service identity access to Key Vault
          (Key Vault → Access policies → Add → Select App Service identity)
          Permission: Get Secrets

  Step 3: Reference the secret in App Service Configuration:
          Name:  DB_CONNECTION_STRING
          Value: @Microsoft.KeyVault(VaultName=myVault;SecretName=db-conn-string)

  Step 4: Application reads DB_CONNECTION_STRING at runtime
          → App Service fetches current value from Key Vault automatically
          → Secret value is injected as an environment variable
          → No secrets stored in the app configuration or code

Key Vault Access Models

Access Policies (Classic Model)

Access policies define which Azure AD identities (users, groups, service principals) can perform which operations (get, list, set, delete) on secrets, keys, and certificates. Each vault has its own set of access policies.

Azure RBAC (Recommended Model)

The newer RBAC model uses standard Azure role assignments to control Key Vault access. This is more granular and consistent with the rest of Azure's access control system.

Key Vault Networking Security

By default, Key Vault is accessible over the internet. For production environments, access should be restricted:

• Firewall rules: Allow only specific IP addresses or Azure service tags to connect.
• Virtual Network service endpoints: Allow access only from specific Azure subnets.
• Private Endpoint: Give Key Vault a private IP address inside a VNet so it is completely inaccessible from the public internet. The most secure option for production.

Soft Delete and Purge Protection

Accidentally deleting a Key Vault or its contents could be catastrophic if secrets or keys for production systems are lost. Azure Key Vault includes safety features:

• Soft Delete: Deleted vaults and objects are retained for 90 days (configurable 7–90 days) and can be recovered during that period.
• Purge Protection: When enabled, deleted vaults and objects cannot be permanently purged during the retention period — even by an administrator. This prevents malicious insiders from immediately destroying evidence after an attack.

Monitoring Key Vault Access

All Key Vault operations are logged to Azure Monitor. The diagnostic logs record who accessed which secret, when, from which IP address, and whether the operation succeeded or failed. These logs are essential for security audits and detecting unauthorized access attempts.

Key Takeaways

• Azure Key Vault securely stores secrets, cryptographic keys, and certificates — keeping them out of application code and configuration files.
• Applications access Key Vault using Managed Identities — no passwords or credentials to manage or rotate.
• The RBAC model provides fine-grained access control: different roles for reading secrets, managing keys, and administering the vault.
• Private Endpoints make Key Vault completely inaccessible from the internet — the recommended setup for production.
• Soft Delete and Purge Protection prevent accidental or malicious permanent deletion of critical secrets and keys.