Azure Key Vault

Azure Key Vault is a cloud service for securely storing and managing secrets (API keys, passwords, connection strings), encryption keys (used to encrypt data), and certificates (TLS/SSL certificates for applications). Instead of embedding sensitive values in application code, configuration files, or environment variables, applications retrieve them from Key Vault at runtime, keeping credentials out of source code and deployment artifacts.

Key Vault comes in two tiers. Standard protects secrets and certificates using software-based encryption. Premium adds support for Hardware Security Module (HSM)-protected keys — cryptographic operations are performed inside tamper-resistant hardware, providing FIPS 140-2 Level 2 (Standard) or Level 3 (HSM) certification. A separate offering, Managed HSM, provides a single-tenant, fully managed HSM for the highest-assurance requirements.

Each Key Vault is created in a specific Azure resource group and region. The vault name must be globally unique within the vault.azure.net namespace. You configure the access model during creation: either the older vault access policies model or the recommended Azure RBAC model where Entra ID roles control read and write access to secrets, keys, and certificates independently.

A secret in Key Vault is any sensitive string value: database passwords, API keys, OAuth client secrets, storage account connection strings. Each secret has a name, a value, and optional attributes like an expiry date and enabled flag. Applications authenticate to Key Vault (typically via managed identity) and call the Key Vault REST API to retrieve the current secret value at runtime — no hardcoded values anywhere.

Key Vault stores cryptographic keys used to encrypt and decrypt data. Services like Azure Storage, Azure SQL Database, and Azure Disk Encryption integrate with Key Vault to use customer-managed keys (CMK) for Bring Your Own Key (BYOK) scenarios. With CMK, you retain control of the encryption key — revoking the key in Key Vault instantly prevents any service from decrypting the data, giving you a cryptographic kill switch.

Key Vault can act as a certificate authority interface for TLS certificates. You can generate self-signed certificates, import existing PFX/PEM files, or configure Key Vault to automatically request and renew certificates from trusted CAs like DigiCert or GlobalSign. When a certificate is about to expire, Key Vault can auto-renew it and notify administrators via Event Grid events, eliminating manual renewal workflows.

Key Vault supports two access models. Vault access policies are the legacy model where you grant a principal permissions to all secrets, keys, or certificates in the vault — you cannot restrict access to individual secret names. The newer and recommended Azure RBAC model uses standard RBAC roles (Key Vault Secrets User, Key Vault Secrets Officer, etc.) and supports deny assignments and Privileged Identity Management, giving much finer-grained control.

A common pattern is referencing Key Vault secrets as App Service application settings. Instead of storing the secret value in the app setting, you store a Key Vault reference: @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/db-password/). App Service automatically retrieves the current secret value at runtime using the app's managed identity. If the secret rotates in Key Vault, the app picks up the new value on the next restart.

Soft delete (enabled by default) retains deleted Key Vault items for 7-90 days, allowing recovery if deletion was accidental. Purge protection, when enabled, prevents anyone — including subscription owners — from permanently purging a soft-deleted vault or its objects until the retention period expires. For regulatory and ransomware resilience purposes, enabling both is a security best practice enforced by Azure Policy.

Every operation against Key Vault — reads, writes, certificate renewals, key usage — is recorded in the Key Vault audit log. You enable diagnostic settings to route these logs to a Log Analytics workspace or a storage account for long-term retention. This provides a complete audit trail of who accessed which secret, when, and from which IP address — essential for security investigations and compliance evidence.

By default, Key Vault has a public HTTPS endpoint on the internet. For high-security environments, you can deploy a private endpoint that places Key Vault inside your VNet with a private IP address, and disable the public endpoint entirely. Applications accessing Key Vault through the private endpoint never traverse the public internet, satisfying data exfiltration prevention requirements and making Key Vault invisible from outside your VNet.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: Key Vault stores secrets, encryption keys, and TLS certificates in a managed, audited service, managed identity integration removes the need for any hardcoded credentials in application code, and soft delete and purge protection guard against accidental or malicious deletion of cryptographic material. Next up we explore Microsoft Sentinel, Azure's cloud-native SIEM.