Hardcoded secrets in code, env vars, or static Secrets are a liability. Modern Kubernetes deployments rotate secrets continuously via external secret stores (Vault, AWS Secrets Manager, GCP Secret Manager). Two patterns dominate: External Secrets Operator and the Secrets Store CSI Driver.
Anti-pattern: K8s Secrets without external store
Native K8s Secrets are base64-encoded (not encrypted at rest by default), live in etcd, and are visible to anyone with cluster admin. For production you need them encrypted at rest AND rotated. Don't rely on native Secrets alone for sensitive data.
External Secrets Operator (ESO)
Watches a CRD called ExternalSecret; pulls value from your external store (Vault/AWS SM/GCP SM); writes a K8s Secret with the value; refreshes every N minutes. Apps read the Secret normally — they're unaware of the rotation. Most popular pattern.
Secrets Store CSI Driver
Mounts secrets as files in pods via a CSI volume. No K8s Secret created at all — secret material only exists in pod memory. More secure (no etcd persistence) but apps must read from filesystem and handle re-reads.
Rotation cadence
DB passwords: rotate every 24 hours. API keys: 7-30 days. TLS certs: 24 hours (with cert-manager). Token-of-the-day for service-to-service: 1 hour. Each tier matches its blast radius.
App-side handling
Long-lived process pools must be notified when a secret changes — restart the pod, or watch the file for changes (SIGHUP pattern). DB connection pool: close idle connections after a rotation to force re-auth with the new password.