Secrets, references & rotation

Runtime fetch by identity, overlap rotation.

A secret is a value with a lifecycle — issued, scoped, rotated, revoked, and audited — not a string you paste into config. Key Vault plus managed identities turn credentials into governed resources fetched at runtime, which is what makes least privilege and rotation practical across an estate.

Fetch at runtime, never embed

A workload should read its secrets from Key Vault at runtime using its managed identity, so nothing sensitive ships in the image, the app settings, or the repo. In App Service and Functions, a Key Vault reference lets an app setting hold a pointer to the secret rather than the value, resolved through the app’s identity — you get the convenience of an environment variable with none of the exposure. Grant Key Vault Secrets User on the specific vault (or specific secrets), never broad access.

# The app setting holds a REFERENCE; the platform resolves it via the app's
# managed identity at runtime. The secret value never appears in config.
az functionapp config appsettings set -g rg -n payments-fn --settings \
  "[email protected](SecretUri=https://app-kv.vault.azure.net/secrets/db-pw/)"
 
# Rotation is scheduled in Key Vault via an Event Grid trigger to a rotation
# function; the app re-reads the reference and picks up the new version.

Rotation with overlap

Key Vault supports scheduled rotation with an Event Grid notification that triggers your rotation logic to create a new secret version. The discipline that makes rotation safe is overlap: keep the old and new versions both valid longer than the longest consumer cache or connection lifetime, confirm every consumer has refreshed, and only then disable the old version. Rotating a secret consumers never re-read either breaks them or defeats the purpose.