security · advanced
Secrets and Key Management
Quick answer
Secrets (tokens, passwords, API keys) and cryptographic keys need controlled issuance, storage, rotation, audit, and revocation. Prefer managed identities and KMS-backed keys over long-lived static secrets in config.
Why this matters
- Leaked secrets are common breach paths.
- Static keys in git/images outlive employees.
- Payments and identity amplify impact.
- Human review required for org-specific controls.
Learning objectives
- Classify secret types. 2. Prefer identity over static secrets. 3. Design rotation and revocation. 4. Scope least privilege. 5. Audit access.
Explain like I am 5
Do not hide house keys under the mat—and change locks when someone moves out.
Mental model
flowchart LR
App --> Identity[Workload identity]
Identity --> KMS
KMS --> DataKey
DataKey --> Data
Core concepts
Hierarchy
Root/HSM keys wrap data keys; apps use short-lived credentials.Rotation
Automate before expiry; dual-publish during windows.Scope
Per-service credentials; no shared "god" keys.Injection
Runtime mount/env from secret manager—not Dockerfile `ENV`.Detection
Alert on secret exfil patterns; break-glass procedures.Worked example
Service used shared DB password in env var from CI. Migrate to workload identity + short-lived DB auth; rotate password; scan git history; alert on password auth usage.
Trade-offs
| Static secrets simplicity | Fully dynamic identity |
|---|---|
| Easy breach persistence | More platform dependency |
Failure modes
| Mode | Mitigation |
|---|---|
| Secrets in git | Pre-commit + scanning |
| No rotation | Automated schedule |
| Overshared vault roles | Per-app policies |
Interview mode
Skeleton: "Short-lived credentials, KMS, rotation, least privilege, never bake secrets into images."
Knowledge check
Workload identity / managed identity with short-lived credentials
Hardcoding passwords in source
Emailing keys in plaintext monthly
Disabling TLS
By Shubham Jain