EIVUS

Secrets Management on Servers

Store and inject API keys, DB credentials safely; avoid env files in repo.

Back to blog

Use a secrets manager (Vault, cloud provider, or dedicated service) and inject at runtime. Never commit secrets to git. Rotate credentials periodically. In Kubernetes, use Secrets or external operator.

Why not .env or repo

  • Risk: .env or config files with secrets in the repo can leak via git history, backup, or copy. Once committed, consider secrets compromised; rotate immediately and purge from history (e.g. BFG, git filter-repo).
  • Best practice: Secrets live in a dedicated store (Vault, AWS Secrets Manager, Azure Key Vault, etc.). Application or startup script fetches them at runtime and injects into environment or config. No secrets in code or in repo.
  • CI/CD: Pipelines need secrets too (e.g. deploy keys, API tokens). Use pipeline secret store (e.g. GitHub Secrets, GitLab CI variables) and never echo or log them.

Secrets manager and injection

  • Vault: HashiCorp Vault — store secrets, dynamic credentials (e.g. DB), encryption as a service. App authenticates (e.g. JWT, AppRole) and reads secrets via API. Integrate with init container or sidecar that writes env or files before app starts.
  • Cloud: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. Native integration with same-cloud workloads; IAM controls who can read. Fetch at boot (user-data, startup script) or via SDK at runtime.
  • Injection: Write to env vars, temp files (with safe permissions), or mount as volumes (Kubernetes Secrets). Application reads from env or file; does not know where the value came from. Restrict filesystem and process access so only the app can read.

Rotation and access

  • Rotate: Change DB passwords, API keys, and certs on a schedule or after incident. Secrets manager can support rotation (e.g. dynamic DB creds with short TTL). Update app or restart so it picks up new values; avoid long-lived static secrets where possible.
  • Access control: Only the app (or the minimal set of processes) should have read access. Use IAM, Vault policies, or file permissions. Audit who accessed which secret and when. Revoke when team members leave or services are decommissioned.
  • Kubernetes: Use Kubernetes Secrets (base64-encoded; consider encryption at rest) or external store with operator (e.g. External Secrets, Vault Agent). Do not put raw secrets in Helm values or ConfigMaps in git.

Summary

Use a secrets manager and inject at runtime. Never commit secrets to git. Rotate credentials periodically. In Kubernetes use Secrets or external operator. Restrict and audit access.

Clients who trust us