Secrets management
Keeping passwords, keys and tokens that programs use in one guarded store, instead of scattered in code and files.
Draft - this entry has not been reviewed yet.
Formal
The practice and tooling for storing, handing out, rotating and revoking machine credentials - such as passwords, cryptographic keys and access tokens - from a central, encrypted store with access control and a log of every use.
In plain English
Like a hotel key desk that hands out room keys only to the right guests, notes who took which key and can cancel a lost one at once - instead of keys hidden under doormats.
In practice
At a pension fund, developers stop writing the database password into the program's code and keep it in a central secrets store; the program fetches it at start-up, and the store changes it automatically every month.
Why it matters
Passwords and keys left in code or shared files are easy for attackers to find and hard to change once leaked; a guarded store limits and records who can use them.
Technical deep dive
The scope is machine credentials: database passwords, API keys, OAuth client secrets, TLS private keys, SSH keys, signing keys and cloud access keys. It overlaps with but differs from key management, where a KMS or HSM performs cryptographic operations and the key never leaves the boundary, and from password managers for humans. Common tools are HashiCorp Vault (relicensed under the Business Source License in 2023, which prompted the OpenBao fork), AWS Secrets Manager, Azure Key Vault and Google Secret Manager. Kubernetes Secrets are only base64-encoded and are stored unencrypted in etcd unless encryption at rest is configured through an EncryptionConfiguration, ideally with a KMS provider.
Stores protect secrets with envelope encryption: a data key per secret or per store, wrapped by a key-encryption key held in a KMS or HSM. Vault encrypts its storage barrier with a root key that is itself protected by Shamir-split unseal keys or by auto-unseal through a cloud KMS. Clients authenticate with a platform identity (a Kubernetes service account token, an AWS IAM role, an OIDC JWT from a CI pipeline) and receive a token bound to policies; secrets come back with a lease and TTL. Dynamic secrets go further: Vault's database secrets engine creates a unique database user per request and drops it when the lease expires, so a leaked credential dies on its own and every use is attributable. Static secrets are rotated instead; AWS Secrets Manager uses a rotation function and the staging labels AWSPENDING, AWSCURRENT and AWSPREVIOUS so that old and new credentials overlap during the switch.
The failure modes are mostly about secrets escaping the store: hard-coded credentials (CWE-798), secrets committed to Git (deleting them in a later commit leaves them in history), baked into container image layers, printed in CI logs, dumped with environment variables into crash reports, or stored in plaintext in Terraform state. Scanners such as gitleaks and TruffleHog, and GitHub secret scanning with push protection, catch many of these. The correct response to a leak is to revoke and rotate first and only then purge history. Every scheme also faces the secret-zero problem: the first credential used to reach the store must come from somewhere trustworthy.
The current direction is to eliminate static secrets altogether through workload identity federation, where a CI job exchanges its OIDC token for short-lived cloud credentials (for example AWS STS AssumeRoleWithWebIdentity), SPIFFE/SPIRE workload identities and short-lived certificates. Relevant references are NIST SP 800-57 Part 1 on key lifecycles and cryptoperiods, ISO/IEC 27001:2022 Annex A 5.17 (authentication information) and 8.24 (use of cryptography), and the OWASP Secrets Management Cheat Sheet.
What to learn first
Everything this builds on, foundations first.
- Cryptographic key
- →Digital identity
- →Service
- →Credential
- →Service account
- →Secrets management
Relationships
- Implements
- Principle of least privilege
- Mitigates
- Data breach
Sources & further reading
Standards & official texts
- NIST SP 800-190 - Application Container Security Guide · NIST
Reference works
- CSA Cloud Controls Matrix (CCM) · Cloud Security Alliance
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Check yourself
Loading…