Secrets management is the practice of storing, distributing, and rotating sensitive credentials such as API keys, certificates, database passwords, and tokens in a controlled and auditable way.
Secrets management systems store secrets in encrypted vaults, enforce access policies, provide short-lived credentials when possible, and rotate secrets automatically. Examples include HashiCorp Vault, AWS Secrets Manager, and Kubernetes external secret stores.
That centralized control replaces scattered secrets in environment variables, config files, and chat messages. Centralization improves auditability, access control, and rotation speed after a leak. The trade-off is operational dependency on the secrets store itself, which must be highly available because application access depends on it.
Think of it like this. Think of a bank vault that hands out temporary access codes instead of copying keys. The codes expire, access is logged, and the real key never leaves the vault.
Applications authenticate to a secrets store using identities, short-lived tokens, or instance roles. The store returns secrets or dynamically generates credentials. Policies control which identities can read which secrets. Rotation jobs replace old secrets before or after a leak window. Audit logs capture access and changes.
"Encryption at rest is enough." Access control, rotation, and audit logging are equally important. "One master secret is fine." Master keys and recovery mechanisms need their own protection. "Secrets in environment variables are safe." Environment variables are often logged, inherited by child processes, or exposed in crash dumps.
Improves security posture and auditability, but introduces a critical dependency and operational overhead. Strong when paired with identity-based access, rotation, and least-privilege policies.