Key Vault and Secrets

A single Azure Key Vault stores three kinds of object, each versioned, each addressable by a data-plane URI of the form https://kv-bookshelf.vault.azure.net/\{secrets,keys,certificates\}/<name>/<version>;:

Every vault is authorized one of two ways, and this is the one place on this site where the underlying API version genuinely changes default behavior rather than just adding flags:

As of Key Vault control-plane API version 2026-02-01, creating a vault with that API version or later defaults enableRbacAuthorization to true — Azure RBAC — unless the create call explicitly sets it to false. This default applies only at create time: updating an existing vault with API 2026-02-01\+ does not change its current access-control model, and a vault whose enableRbacAuthorization is null (created with an older API) keeps using access policies until someone changes it. Separately — and this is the deadline to actually plan around — every Key Vault control-plane API version before 2026-02-01 is retired on 2027-02-27; after that date, calls made with an older API version are suspended, independent of which access-control model a vault uses. Azure CLI 2.90.0\+ and Azure PowerShell 16.3.0\+ already call API 2026-02-01\+, so keeping the CLI current is the simplest way to stay ahead of that retirement. kv-bookshelf is created below with Azure RBAC, matching the current default.

Soft delete is on by default for every vault and, once enabled, can never be turned off. Deleting a vault, or an individual secret/key/certificate, does not remove it immediately: it moves to a soft-deleted state, listable and recoverable for a retention period configurable only at creation time, from 7 to 90 days (default 90) — the --retention-days flag above. A second, explicit purge operation is required to permanently remove a soft-deleted vault or object, and only a principal holding Key Vault Purge Operator (or, for a vault itself, a subscription Owner) can issue it. Two consequences worth planning around: a vault name (and, within a vault, an object name) cannot be reused until the retention period expires or the soft-deleted item is purged, and recovering a soft-deleted vault does not restore services that were integrated with it, such as Azure RBAC role assignments scoped to the vault or Event Grid subscriptions on it — those must be recreated.

Purge protection is an optional, one-way addition on top of soft delete: once enabled, nobody — not even a subscription Owner — can purge a soft-deleted vault or object before its retention period elapses; it can only expire naturally or be recovered. Most Azure services that use customer-managed keys (Storage, SQL) require purge protection on the vault they point at, to prevent a key’s premature purge from causing permanent data loss. kv-bookshelf enables it below; production vaults holding encryption keys should always enable it. The flip side, for a walkthrough like this one: once purge protection is on, kv-bookshelf cannot be purged after it is deleted, so its name stays reserved for the full 90-day retention period (see Clean up). Skip the purge-protection step on a throwaway learning vault whose name you want to reuse immediately.

Every write to a secret creates a new, immutable version; reading a secret by name without a version returns the latest one. Both secrets and keys accept optional not-before and expires timestamps, enforced by the data plane itself (an expired secret’s value cannot be retrieved even by a principal with full permissions) — Bookshelf sets these on anything with a known rotation cadence, such as a partner API key.

Creating a certificate with az keyvault certificate create and a policy (subject name, key type, validity period, issuer, and lifetime actions) drives the whole lifecycle: Key Vault generates the key pair, requests or self-issues the certificate per the policy, and stores the result as an addressable key + secret
certificate. The default policy (az keyvault certificate get-default-policy) is a self-signed certificate with an AutoRenew lifetime action triggered at 80% of its validity period elapsed; a custom policy can instead trigger on EmailContacts only, or at a specific day count before expiry. Renewing an integrated-CA or self-signed certificate this way creates a new secret version automatically; a non-integrated-CA certificate instead produces a certificate signing request (CSR) to download, sign externally, and merge back in.

A newly created vault’s firewall is disabled by default: every Azure service and public caller can reach the data-plane endpoint, though Microsoft Entra authentication and role/policy checks still gate every operation — disabling the firewall does not disable authorization. Enabling the firewall moves to a default-deny model with explicit allow rules:

Bookshelf reads secrets from kv-bookshelf four different ways, chosen per compute host rather than per secret.

Key Vault does not log data-plane access by default; enabling it is a per-vault diagnostic setting, same as any other Azure resource, sending the AuditEvent (every data-plane call, its caller, and its result) and AzurePolicyEvaluationDetails categories to a Log Analytics workspace, a storage account, or an event hub. This is the audit trail that shows who read orders-db-connection-string and when, independent of Azure RBAC’s own activity log (which covers control-plane changes to the vault, not data-plane reads).

Derived from Azure Key Vault logging.

Standard and Premium vaults bill per operation (secret/key/certificate get, set, list, …​) plus a small per-managed-key monthly charge for HSM-protected (Premium) keys and per-renewal charge for managed certificates — the dominant driver in practice is operation volume, which is why Path 2’s 24-hour/30-minute caching and Path 3’s CSI volume mount (read from the mounted file, not a fresh Key Vault call per request) matter as much for cost as for latency: an application that called SecretClient.getSecret on every request instead of caching it in memory would multiply its Key Vault bill by its request volume for no benefit, since the underlying secret rarely changes between requests. A soft-deleted object in the retention window bills nothing except its own purge/recover calls (and, for an HSM key, its per-version monthly charge if used within the last 30 days). Managed HSM bills per HSM pool per hour instead of per operation, which is the other reason it is reserved for workloads that actually need a dedicated hardware boundary. Current rates are on the Key Vault pricing page, which should be checked before sizing any of the above for a real workload.

Because purge protection is enabled on kv-bookshelf, az keyvault purge is refused: the vault stays soft-deleted, and its name reserved, until the 90-day retention period set at creation elapses, after which Azure purges it automatically. Within that window it can still be brought back with az keyvault recover --name kv-bookshelf. For a disposable vault created without purge protection, az keyvault purge --name <vault> --location "$LOCATION" frees the name immediately — but only after the resource-group deletion has finished (hence no --no-wait above), since a vault can’t be purged before it has been soft-deleted.

Derived from Azure Key Vault recovery overview.