Dynamic Secrets: Temporary On-Demand Credentials

WHY IT EXISTS: Static secrets like database passwords or API keys stored in environment variables and config files rot slowly. When a developer leaves, a key leaks, or a compliance audit arrives, teams must rotate them manually across dozens of services. This is toil-prone and error-prone. Dynamic secrets were invented to remove the long-lived credential from the equation entirely so there is nothing to leak and nothing to rotate by hand.

THE MENTAL MODEL: Think of a dynamic secret as a hotel key card instead of a house key. A house key is cut once and grants access forever; if copied, the lock is compromised until you change it. A hotel key card is programmed at check-in, works only for your room, and automatically deactivates at checkout. In software, the CI pipeline checks in with a vault, receives a temporary credential, uses it, and the credential dies on its own.

HOW IT WORKS: A central secret engine such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault generates credentials on the fly by calling the target system itself. For example, Vault can create a new PostgreSQL role with a random password and a time-to-live of fifteen minutes. The CI job receives this username and password, runs migrations or deploys code, and the secret engine revokes the role when the lease expires. The application never sees a master password and cannot accidentally cache a permanent credential.

WHEN TO USE IT: Use dynamic secrets when you have automated pipelines that touch production databases, cloud APIs, or third-party services and you want to shrink the blast radius of a breach. They shine in microservices architectures where many workloads need distinct credentials, in regulated environments that demand regular rotation, and in scenarios where humans should never possess a permanent root password.

WHEN NOT TO USE IT: Do not use dynamic secrets for bootstrapping problems where the secret engine itself needs a credential to start, or for long-running batch jobs that outlive the lease duration unless you build complex renewal logic. They also add latency and a network dependency to every deploy, so they are a poor fit for air-gapped edge devices or systems that must survive a total control-plane outage.

ONE CANONICAL EXAMPLE: A GitHub Actions workflow deploys a Node.js service to Kubernetes. At the start of the job, it authenticates to HashiCorp Vault using its OIDC identity token and requests a dynamic AWS credential with an IAM policy scoped to a single S3 bucket. Vault calls the AWS STS API and returns a temporary Access Key ID, Secret Key, and Session Token valid for ten minutes. The workflow uploads the build artifact to S3, the lease expires, and the keys become useless. If the job logs are later leaked, the attacker finds credentials that were revoked before they could be used.