How dynamic secrets work
A dynamic secret is a credential that does not exist until the moment it is needed. When a client — an application, a pipeline, an engineer — requests access, the secrets engine mints a fresh credential for that specific client and that specific purpose, attaches a lease with a defined lifetime, and hands it over. When the lease expires, the credential is revoked automatically on the target system; nobody has to remember to clean it up. A static secret works the other way around: it is created once, copied into configuration files and pipelines, and lives on until someone remembers to rotate it — which in practice can be months or years.
The pattern fits any backend that can create and delete credentials programmatically. The most common targets are databases, where each session gets its own short-lived database user instead of a shared account; cloud providers, where temporary credentials are issued per task instead of long-lived access keys; and Kubernetes, where service account tokens are minted on demand rather than stored. In each case the target system only ever sees credentials that were born recently and will die soon.
Why they matter
The security argument is simple: a credential that does not exist cannot be stolen. Static secrets accumulate in code repositories, CI variables, and configuration files, and every copy is a standing target that stays valid until rotation. With dynamic secrets there is nothing standing to steal — an attacker who compromises a machine finds, at worst, a credential that expires in minutes or hours, so the blast radius of any leak is bounded by the lease length. Every mint and every revocation passes through the secrets engine, so there is a complete audit trail of who received which credential and when.
Attribution improves for the same reason. When five services share one database password, the database log cannot say which of them ran a given query. When each client receives its own credential, every action on the target system traces back to a specific identity. This is also how dynamic secrets connect to the broader principles of zero standing privilege and just-in-time access: access exists only in the moment it is exercised, granted on request and withdrawn automatically, rather than sitting idle waiting to be misused.
Adopting dynamic secrets
The main engineering consequence is that applications must tolerate credential refresh. Code written against a password that never changes will break when the lease expires, so clients need to fetch credentials at startup, renew or re-request them before expiry, and reconnect gracefully when a credential is replaced. Most modern database drivers and cloud SDKs handle this well, but it is a design property to verify per application rather than assume. Lease lengths are a tuning decision: short enough to bound exposure, long enough not to churn connections unnecessarily.
The second requirement is central control. Leases must be revocable from one place — when an incident occurs or a machine is compromised, the operator needs to cut every credential issued to that client immediately, not hunt through target systems. That is why dynamic secrets are delivered by a secrets management platform rather than scripted ad hoc: the platform owns issuance, renewal, revocation, and the audit record as one lifecycle. Monopam’s secrets management mints dynamic PostgreSQL, MSSQL, MySQL, and Kubernetes credentials with auto-expiring leases.