Secrets management is the discipline of handling the sensitive values that software needs in order to run - database passwords, API keys, TLS private keys, encryption keys, and access tokens - in a way that keeps them confidential while still making them available to the applications and automation that legitimately require them. The core difficulty is that modern systems depend on many such secrets, and the naive approaches (hardcoding them in source code, baking them into images, or passing them around in plaintext files) scatter credentials across many machines and version-control histories where they are easy to leak and hard to rotate.
The HashiCorp Vault documentation frames the problem plainly: “Modern software works because of secrets,” yet those secrets are typically spread across an organization with little centralized oversight. Vault, released by HashiCorp in 2015, became a widely cited reference implementation for the category. It provides a centralized service where clients authenticate through one of many methods - tokens, LDAP, cloud IAM roles such as AWS or Azure - and then receive access scoped by policy to particular secret paths. Crucially, “Vault audits all activity, regardless of whether authentication or authorization succeeds,” giving operators a tamper-evident record of who requested which secret and when.
A defining property of good secrets management is that secrets are encrypted at rest and never persisted in cleartext where automation can accidentally expose them. Vault’s documentation describes storage backends such as integrated Raft storage that “encrypts and replicates data across an operating Vault cluster.” Beyond static storage, mature systems support dynamic secrets that are generated on demand and automatically expire, and rotation that changes long-lived credentials on a schedule so that a leaked value has a short useful life.
Secrets management is the operational answer to the Twelve-Factor App principle of keeping config - and especially credentials - out of the codebase and in the environment. Where the twelve-factor methodology says secrets should not live in source, secrets management systems answer the harder follow-up question: if not in source, then where, and how does a freshly started container or a CI job retrieve them securely at the moment of use? Cloud providers offer their own services for this, such as key management services (KMS) and managed secret stores, and Kubernetes adds primitives like sealed secrets for storing encrypted secrets safely in a Git repository.
The practice sits at the intersection of security and automation. Because infrastructure-as-code and continuous delivery pipelines run unattended, they cannot prompt a human for a password; they must fetch secrets programmatically. This is why secrets management became a first-class concern of DevOps: it lets fully automated systems obtain exactly the credentials they need, with least-privilege scoping, short lifetimes, and a complete audit trail, instead of relying on long-lived secrets copied into configuration files.