Secrets Management (ops view)

Secrets Management (Ops View)

• Goal: secrets are never committed, logged, or copied into images.
• Prefer short-lived credentials and automated rotation.
• Separate storage (vault/KMS) from delivery (injection at runtime).

Practical Do and Don't

• Do: inject via environment variables or mounted files with strict permissions.
• Don't: print secrets in app logs, CI logs, or kubectl describe output.
• Do: rotate on schedule and after incidents.

Kubernetes Safe Patterns

# Create secret from literal (avoid shell history; prefer files in real life)
kubectl -n app create secret generic db-creds 
  --from-literal=username=app 
  --from-literal=password="$(openssl rand -base64 24)"

# Mount as file (less likely to leak into process listings than env vars)
# (Pod spec excerpt)
volumes:
- name: db
  secret:
    secretName: db-creds
containers:
- name: api
  volumeMounts:
  - name: db
    mountPath: /var/run/secrets/db
    readOnly: true

Leak Response Runbook

1. Revoke/rotate immediately (assume compromise).
2. Find blast radius: where used (pods, CI, configs).
3. Invalidate sessions/tokens if applicable.
4. Remove secret from logs/artifacts and reduce retention if needed.