Key and Secret Management¶
The best secret is one that doesn't exist. The platform's own pipelines already work without any stored secrets, using federated OIDC credentials. This page extends that principle to workloads, and sets the Key Vault standard for the secrets that can't be avoided.
Status: in place for platform pipelines, planned for workloads
No platform pipeline stores a secret. The Key Vault standard below is checked by policy in audit mode only (psa-kv-Security, psa-kv-Governance).
Order of preference¶
- No secret at all: use managed identities for Azure-to-Azure access (an app reading a database, a function reading storage), and Entra ID authentication instead of keys or connection strings.
- A federated credential: for pipelines and external systems that support OIDC, such as GitLab, GitHub and some SaaS vendors. Nothing is stored and nothing expires.
- A secret in Key Vault: only when the other system supports nothing better. Read it at runtime with a managed identity, and never copy it into app settings or pipeline variables.
- Never: secrets in code, in Terraform variables committed to git, or in CI variables for Azure access.
Terraform state holds secrets
Any secret Terraform creates or reads, such as a generated password or a storage key, is stored in plain text in state. This is one reason state storage is Tier 0 or tightly scoped (see Terraform State Storage). Where possible, generate secrets outside Terraform, or use ephemeral resources and write-only arguments so they never reach state.
Key Vault standard¶
| Setting | Standard | Why |
|---|---|---|
| Permission model | Azure RBAC (not access policies) | One access model across the platform, managed by groups and PIM |
| Soft delete and purge protection | Both on | A deleted vault or secret can be recovered and can't be purged early |
| Network access | Private endpoint, with public access disabled for production | Secrets aren't reachable from the internet |
| Diagnostic logs | Sent to the central workspace | Every secret read is recorded |
| Secret expiry | Every secret has an expiry date | Forces rotation, and the Defender recommendations track it |
| One vault per workload and environment | No shared vaults across workloads | Limits the blast radius and keeps access simple |
| Defender for Key Vault | On for vaults holding production secrets | Detects unusual access. See Defender Plans. |
Rotation¶
- Automate rotation where the service supports it, for example Key Vault rotation policies for keys and Event Grid-triggered rotation for secrets.
- At least every 90 days for anything rotated by hand, and immediately if exposure is suspected. See Incident Response.
- Certificates come from Key Vault with auto-renewal where the issuer supports it.