Secret management
Securely storing, distributing, and rotating secrets (API keys, certs, DB passwords) instead of hardcoding them. Vault, AWS Secrets Manager, and cloud KMSs do this. Secrets are injected at runtime, never in code or images.
- Any non-trivial app with secrets.
- Compliance requiring rotation and audit.
- Single-dev prototypes (env vars suffice).
- When the secret manager becomes a fragile dependency.
Definition
A secret manager stores secrets encrypted, controls access via policy, and delivers them to workloads at runtime (env, files, sidecar). It supports rotation, audit, and short-lived credentials. Never commit secrets to source or bake into images.
Why it exists
Hardcoded secrets leak via source, logs, and images and can't be rotated. Centralized secret management keeps them out of code, rotates them, and audits access.
How it works
Store secrets in a vault/KMS. Workloads fetch at startup or via a sidecar/mount. IAM grants access. Rotation updates the secret and consumers. Short-lived dynamic secrets (DB creds) limit blast radius. Audit logs every access.
Scaling limits
The secret manager is a critical dependency (outage blocks app startup). High fetch rates need caching. Rotation must update all consumers atomically to avoid downtime.
Cost shape
Managed service per-secret + API calls; self-hosted Vault needs infra + ops. Blow-ups: over-frequent fetches and unmanaged rotation.
Alternatives
- Env vars / config files — Simple but no rotation/audit and prone to leaks.
- Cloud IAM roles — No secret to manage for same-cloud access, but cloud-specific.
Failure modes
- Secrets in source/images (leaks).
- Rotation breaking consumers.
- Vault outage blocking startup.