Guide

A secret is any credential or key that grants access. Examples are a database password, an API token, a TLS private key and a cloud access key. The usual failure is that a secret leaves the place that can audit and rotate it. After that, it can live for years in git history, a chat paste, a container image or a laptop .env file.

Concept

Before you start. Encryption protects data. Secrets management protects the keys and passwords that unlock it. For the encryption basics, read crypto basics.

Six stages

Treat each secret as having a lifecycle, not a one-time paste.

  1. Create it in a controlled store, or generate it on demand.
  2. Distribute it only to identities that need it, over authenticated channels.
  3. Use it in memory. Inject it at process start, or fetch it when needed.
  4. Rotate it on a schedule, and whenever you suspect a leak.
  5. Revoke it at once when it is compromised. Confirm that everything that depends on it has the new value.
  6. Audit every read and write.

Each stage is a place where things go wrong:

StageCommon failure
CreateA password typed by hand into a config file
DistributeThe password is sent in a chat or a ticket
UseThe password is written to logs
RotateNever done, because nobody knows what depends on it
RevokeThe old value still works for weeks
AuditNobody can say who read it

Static and dynamic secrets

A static secret is a password a person chose. It lasts until someone changes it, which makes it a long-lived target.

A dynamic secret is minted by the system for one job and expires on its own. If a dynamic credential leaks, it dies within its time limit. The secret stores page shows how Vault creates one.

Concept

Rotation means replacing a secret with a new value and retiring the old one. If you cannot rotate without an outage, you do not have a secrets system yet. You have a shared password. The rotation page covers how to do it safely.

Owners and maximum age

Every secret needs an owner, usually a service or team tag, and a maximum age. Secrets without owners become zombies. Nobody dares rotate them, because nobody knows what will break.

Common mistakes

  • Treating a secret as a one-time paste. The lifecycle continues after the first deploy.
  • Committing a secret "temporarily." Git history keeps it even after you delete the file.
  • Sharing one admin password. Give each identity its own access, so you can audit and revoke it.

Check yourself

  1. What is the difference between a static and a dynamic secret? Answer: a static secret lasts until someone changes it. A dynamic secret is minted per job and expires on its own.
  2. A password was pasted into a ticket. Which stage failed? Answer: distribute. It went to a place with no access control and no audit trail.

Key takeaways

  • A secret has a full lifecycle: create, distribute, use, rotate, revoke, audit.
  • Static secrets are a liability. Use dynamic secrets when the system can mint them.
  • Every secret needs an owner and a maximum age.
  • Next, where secrets live compares the places to keep them.

Further learning

Secrets Management Cheat Sheet (OWASP)Website with the collection of all the cheat sheets of the project.cheatsheetseries.owasp.org Dynamic secrets for database credentials (HashiCorp Vault)Dynamically generate, manage, and revoke database credentials that meet your organization's password policy requirements.Dynamic secrets for database credential management | Vault | HashiCorp Developer NIST SP 800-57 Part 1: Recommendation for Key ManagementThis Recommendation provides cryptographic key-management guidance. It consists of three parts. Part 1 provides general guidance and best practices for the management of cryptographic keying material, including defini…CSRC | NIST

Armon Dadgar's whiteboard introduction explains why secret sprawl happens and how dynamic, leased secrets fix it.

Introduction to HashiCorp Vault with Armon DadgarHashiCorp, an IBM Company