Secrets Management
This is the day-to-day side of handling secrets: how the application gets the credentials it needs at runtime, how they rotate, and how the team shares access. It is the practical workflow behind the strict rules in Secrets at Rest & in Transit. The vault is the single source of truth, and everything else points to it.
Good secrets management makes the secure way the only easy way. The application reads secrets from a managed vault at runtime using its own identity. Developers never hold production secrets. Rotation is routine and automated. Access is granted, scoped, and revoked through the vault, not passed around. With that workflow in place, secrets have nowhere to leak from.
The Finperiti sample kept secrets in raw configuration, with no Key Vault. The workflow itself was the vulnerability. Fixing it is less about any one secret and more about adopting the pattern: vault-held secrets, identity-based access, and managed rotation. Then no human and no repo ever needs to hold a production credential.
Source secrets from a vault
- AlwaysKeep all secrets in a managed vault (Azure Key Vault). Have the application read them at runtime through its managed identity, not from files it ships with.
- DoReference secrets (Key Vault references or configuration providers) so application config holds pointers, never values.
- DoScope each secret to the smallest set of services and environments that need it. Keep dev, test, and prod fully separate.
- ConsiderShort-lived, automatically issued credentials (managed identity tokens) instead of long-lived static secrets wherever the platform supports it.
- NeverCommit, hard-code, or store secrets in plaintext config, env files, or source. Share access only through the vault.
// appsettings.Production.json, in the repo
"Stripe": { "ApiKey": "sk_live_51H..." }
A live payment key in source control: readable by everyone with repo access, impossible to rotate without a redeploy, and one leak away from disaster.
// config holds a reference, resolved at runtime via the app's managed identity
"Stripe": { "ApiKey": "@Microsoft.KeyVault(SecretUri=https://kv.../stripe-key)" }
No secret in the repo. Rotation happens in the vault with no redeploy, and every read is authenticated and audited.
Rotate, audit, and respond
- DoMake rotation routine, and automated if possible, with overlapping validity so a rotated secret never causes downtime.
- DoAudit access to the vault (who read or changed which secret, and when) and alert on unusual access.
- DoHave a practised response for exposure: rotate immediately, assess the impact, and treat it as an incident.
- ConsiderKeeping a documented inventory of what secrets exist, what they are for, and how often they rotate.
- Do notLet developers keep standing copies of production secrets, or share them through chat, tickets, or screenshots.
- NeverReuse one secret across environments or services, or leave a known-exposed secret in place. Rotate it and treat it as a breach.
Self-review checklist
- AskDoes the app get this secret from the vault at runtime, or is the value sitting in config or code?
- AskCan this secret be rotated without a code change or downtime?
- AskDoes anyone hold a standing copy of a production secret who should not?
- AskIf this secret leaked, is the response (rotate and treat as an incident) clear and practised?