What are secrets and where to store them

Topic: Security basics

Secrets are credentials (passwords, keys, tokens) that must stay confidential. Store them in a dedicated secret manager or vault, not in code or config files in repo. Use this when adding a new service or moving secrets out of config.

Intent: How-to

Quick answer

  • Secrets are passwords, API keys, private keys, and tokens. Never commit them to git; do not put them in plain config files or environment files committed to repo.
  • Store in a secret manager (HashiCorp Vault, cloud provider secrets), or in env vars injected at runtime (not in a file in the image). Restrict access with IAM or ACLs.
  • Rotate secrets when leaked or when someone leaves; use short-lived tokens where possible so rotation is built in. Audit who can read and use each secret.

Prerequisites

Steps

  1. Identify secrets

    List all credentials the app or system needs: DB passwords, API keys, private keys, tokens. Treat anything that grants access as a secret; do not log or expose in errors.

  2. Choose storage

    Use a secret manager or vault so secrets are fetched at runtime, not baked into images or config. If no vault, use env vars set by the orchestrator or deployment system, not committed to repo.

  3. Restrict access

    Only the process that needs the secret should have read access. Use IAM, RBAC, or file permissions; audit who can read and use secrets; prefer short-lived credentials.

  4. Rotate and revoke

    Rotate secrets on a schedule or when compromise is suspected; revoke when a person or service no longer needs access. Document how to rotate so it can be done quickly.

Summary

Secrets are credentials that must stay confidential. Store them in a secret manager or vault; never in code or committed config. Restrict access, rotate, and revoke when needed.

Prerequisites

Steps

Step 1: Identify secrets

List every credential the system uses. Treat anything that grants access as a secret; do not log or expose it.

Step 2: Choose storage

Use a secret manager or vault. If not available, use env vars set at deploy time, not in files in the repo.

Step 3: Restrict access

Grant read access only to the process or role that needs the secret. Audit access; prefer short-lived credentials.

Step 4: Rotate and revoke

Rotate on a schedule or after suspected compromise; revoke when access is no longer needed. Document rotation steps.

Verification

No secrets in git or in plain config in the repo; secrets are loaded from a vault or env at runtime; access is restricted and auditable.

Troubleshooting

Secret in git history — Rotate the secret immediately; consider history rewrite or tools to purge. No vault — Use env vars from deployment; plan to adopt a secret manager.

Next steps

Continue to