Dynamic Secrets

Static secrets have an unavoidable set of problems: they exist somewhere at rest, they are shared between consumers so a leak is unattributable, rotation requires coordination across everything using them, and revocation means changing the credential everywhere at once.

Dynamic secrets remove the category. A workload asks the secret manager for database access; the manager creates a new database user with the required grants, returns it with a lease of an hour, and revokes it on expiry. Nothing is stored, nothing is shared, and revocation is a lease cancellation.

Two properties follow that are worth noting. Attribution becomes possible — each credential is unique, so database audit logs identify the specific workload and time, which static shared credentials can never do. And rotation stops being an event: it happens continuously by construction, so the annual rotation project disappears.

What it demands: the secret manager becomes critical infrastructure on the request path (mitigated by caching the lease and renewing before expiry, not on every use), applications must handle credential expiry gracefully rather than caching a connection forever, and the target system must support programmatic credential creation.

Available for databases, cloud providers, SSH, PKI and message brokers. Worth adopting first for the highest-value data stores rather than everywhere at once.