Infrastructure Secrets Management Without Complexity

Secrets management can start with a simple rule: credentials, tokens, private keys, and connection strings do not belong in Git, container images, chat, or shell history. Keep a redacted example in the repository, inject the real value at runtime, and enable secret scanning or push protection. If a secret reaches a repository, treat it as compromised: revoke or rotate it, then investigate where it was copied.

A practical baseline is one secret store per environment, narrowly scoped identities, and a named owner for every important credential. Give applications only the paths and operations they need. Rotation should be tested as an ordinary deployment operation, not postponed until an incident. Start with a small inventory—database passwords, cloud keys, CI tokens, and TLS material—and record how each item is issued, consumed, rotated, and revoked.

Vault becomes useful when shared credentials, dynamic database access, leases, or central policy justify another service. Vault policies are path-based and deny by default; its database secrets engine can issue short-lived credentials instead of hard-coded ones. That power adds work: authentication, availability, backups, upgrades, and recovery need owners. For a small stack, a managed secret manager or CI secret store may be calmer.

GitOps does not mean committing plaintext. Keep declarative configuration in Git while a deployment step obtains secrets externally. Kubernetes Secrets still need encryption at rest and least-privilege RBAC; base64 is not encryption.

Sources: HashiCorp Vault policies, Vault database secrets engine, Kubernetes Secrets guidance, and GitLab secret-management practices.