Deep dive
**Config** is non-sensitive (feature flags, timeouts, endpoints). **Secrets** are sensitive credentials (API keys, DB passwords, signing keys). The goal is to prevent accidental exposure and enable controlled rotation.
Recommended approach
- Store secrets in a managed secret system (cloud Secret Manager / Vault) backed by encryption (KMS).
- Grant access via identity (IAM role/service account), not by hardcoding keys.
- Inject secrets at runtime (env vars or mounted files) and keep them out of:
- git repos,
- container images,
- build logs and CI output.
Operational practices
- Rotate secrets regularly and on incidents.
- Use least privilege (separate credentials per service/environment).
- Prefer short-lived credentials when possible (STS, workload identity).
Common pitfalls
- Putting secrets into `.env` committed to git.
- Sharing one secret across many services (blast radius).
- Logging secrets accidentally (debug logs, error messages).