Secret Management
Centralized secret storage and rotation with HashiCorp Vault - static, dynamic, and short-lived credentials
Secret Management
Every system has secrets — database passwords, API tokens, TLS keys, signing keys, third-party credentials. A secret manager is the dedicated, audited, access-controlled store for them. Without one you end up with secrets in .env files, S3 buckets, Slack DMs, and git log — all very bad.
This section focuses on HashiCorp Vault, the de-facto open-source choice, with notes on cloud-native alternatives.
Why a Dedicated Secret Manager
| Without | With Vault (or similar) |
|---|---|
| Secrets in env files, env vars, code | Central store; apps fetch at runtime |
| Manual rotation, often skipped | Programmatic rotation; dynamic short-lived creds |
| No audit trail of who read what | Every read logged with identity and timestamp |
| Static long-lived creds in CI | Workload identity → short-lived token from Vault |
| One leak compromises everything | Per-app least-privilege paths; revoke individually |
Static vs Dynamic Secrets
The biggest mental shift from "store passwords in a vault."
| Mode | What you store | Lifetime | Example |
|---|---|---|---|
| Static | The secret itself | Long | A pre-existing DB password you uploaded |
| Dynamic | Credentials to create secrets on demand | Seconds to hours | "Give me a Postgres user that exists for 1 hour" |
| Leased | Either, but with a TTL and renewal | Configurable | All Vault secrets carry leases |
Dynamic secrets are Vault's killer feature. Your app asks Vault for a database connection, Vault asks the database to create a user with CREATE ROLE ... VALID UNTIL 'now+1h', hands the credentials back, and revokes them when the lease expires. The app never sees a permanent password, and a leak is bounded.
The Players
| System | Notes |
|---|---|
| HashiCorp Vault | Open-source + enterprise; the broad-spectrum standard |
| AWS Secrets Manager | Native to AWS; auto-rotation Lambdas; pay-per-secret |
| AWS SSM Parameter Store | Simpler/cheaper than Secrets Manager; static secrets only |
| GCP Secret Manager | GCP equivalent |
| Azure Key Vault | Azure equivalent |
| Doppler / 1Password Secrets | SaaS-first, dev-friendly UX |
| Infisical / Bitwarden Secrets | Open-source SaaS alternatives |
| SOPS | File-based encryption (not a service); good for GitOps |
| Sealed Secrets | Encrypts Kubernetes Secrets for git-storable form |
Vault wins for: dynamic secrets, multi-cloud, multi-tenant, advanced auth methods, transit encryption, PKI engine.
Learning Path
1. Getting Started
Run Vault in dev mode, write and read a secret, enable an auth method
2. Dynamic Secrets
Generate short-lived database, cloud, and PKI credentials on demand
3. Best Practices
HA topology, unsealing, auth methods, K8s integration, audit, disaster recovery
What a Secret Manager Doesn't Do
A common pattern: teams adopt Vault, then keep doing the same things slightly differently. Avoid these:
| Anti-pattern | Why it's bad |
|---|---|
| Storing secrets in env files and Vault | Two sources of truth; the env file will drift and leak |
Long-lived VAULT_TOKEN env vars in production | The token itself becomes the new long-lived secret |
| Treating Vault as a config store | Configs aren't secrets; they belong in code / ConfigMaps |
| Manual rotation on a quarterly cadence | If you can rotate, you can rotate weekly; if you can't rotate, why bother? |
| One root token shared by a team | The whole point is per-app identity and audit |
Vault unlocks dynamic, short-lived, audited credentials. The point isn't where secrets live; it's that they shouldn't live for long.
Secret management overlaps with Service Mesh (mTLS identity) and Kubernetes (workload identity, ServiceAccount tokens). The integration is the interesting part — see Best Practices for how they fit together.