Rotated vs. dynamic secrets: Which should you use?

Secrets are anything that can be used to authenticate or authorize people or machines to gain access to resources and take action. Secrets can be passwords, API tokens, certificates, or keys to connect to critical business applications. At a high level, secrets fall into four categories: unmanaged (not securely stored), static, rotated, and dynamic.

Static secrets or credentials are key value-pairs, such as username and password, used to access some kind of system. They are the most common type of secret organizations use to secure access to applications, sensitive data, or machines. Static secrets are typically not rotated very often because of the operational overhead of doing so. If they are not securely stored and centrally managed, then they are unmanaged and become a liability for downtime or even breach. The longer a credential lives on, and the more people that have access to it, the more likely this secret could be exposed and cause a breach.

The best first step to securing static secrets and credentials is to centrally store and manage them in a dedicated secrets management tool that encrypts the secret and requires identity-based authorization for access. These secrets should then be changed on a regular basis, either through regular automated rotation or dynamic auto-generation and deletion when needed. The main reason teams don’t do this is because they don’t have the systems in place to automatically rotate or generate secrets. When secret rotation is a manual burden, they often don’t get rotated until a breach happens. For many organizations we talk to, they need to create a ticketed workflow to change a secret, taking hours of a developer’s time and days or weeks to complete.

Out of the four types of secrets listed above, this blog focuses on two that have many similarities: Rotated and dynamic. By learning the differences between auto-rotating secrets (often just called “rotation”) and dynamic secrets, you’ll better understand the best-fit use cases for each type.

»Automating secrets management

Auto-rotated and dynamic secrets are different strategies for accomplishing the same goal: automating the management of a secret in order to reduce the amount of time it could be used if obtained by a threat actor. Sometimes these two concepts are confused or conflated, and you might see phrases such as “auto-rotating dynamic secrets.” While they share a similar goal, their workflows for managing secret lifecycles are different.

»Auto-rotated secrets

Automating the rotation of secrets enables organizations to improve their security stance by ensuring that their static secrets aren’t long-lived. Auto-rotated secrets can be shared by multiple instances of an application or workload.

When a secret rotation occurs, one or sometimes multiple new versions are stored as the latest version(s) for the secret. At the same time, an older version(s) of the secret becomes inactive. When an instance of the application starts up it will pull the latest version of the secret. This secret is shared between any other instance that has accessed the latest credential during the same rotation window.

If the secret becomes invalid, it affects many instances of the application. Pre-creating and sharing secrets among consumers allows for low latency and less error-prone secret retrieval. A temporary outage of the rotation mechanisms will delay new credentials from being created but existing ones will still be active. Since rotation periods are likely to be in the days or months range, auditing historical secret values becomes easier.

Secret rotation generally occurs in four phases, whether it is configured to enable one secret or two secrets to be active at one time. If your secret management tool provides the ability to support more than one active version of a secret, then the latest of the two versions will be returned by default. Enabling more than one active version of a secret is preferable because it gives the user a guarantee that the secret is safe to use for at least the rotation interval of this latest active version. For this example, we will assume that only one secret at a time will be active, but the process works the same.

1. Creation: Rotating secrets are created on a schedule by a secrets management system. When a rotation happens, a new credential(s) is stored as the active/latest version of the secret. At the same time, an older version of the credential becomes inactive. Version 1 in the diagram above is the current active secret which is approaching the end of its rotation timeline. When this happens, version 2 will be created as the next active secret.

• Version 1 secret: The one currently in use.
• Version 2 (pending): The newly created secret, awaiting validation.

2. Testing: The newly generated version 2 secret is subjected to a verification process to ensure its validity and functionality. This involves conducting checks or tests that simulate actual operations the secret would perform.
3. Activation: The system promotes version 2 to be the new current active secret. It then triggers any necessary follow-up tasks, such as invoking webhooks and queuing the secret for synchronization with dependent workloads.
4. Deletion: Post-verification, the system deactivates and deletes version 1

»When to use auto-rotated secrets

Auto-rotated secrets are well suited for more static or critical workloads where frequent restarts can cause performance issues or outages. An example would be a long-lived workload or application that requires continuous access to a database or cannot handle credential updates without restarts.

Another use case might be for long-lived workloads that need to comply with standards such as the Payment Card Industry Data Security Standard (PCI DSS) or System and Organizational Controls (SOC) requirements. PCI security standards, for example, require that passwords must be changed at least every 90 days.

»Dynamic secrets

Dynamic secrets help you manage intentions instead of managing credentials, (e.g. a web server needs secure database access).

They are created just-in-time by an issuing service when the secrets management system requests one. During creation, a background task is initiated to clean up the credential after some predefined amount of time (this lifespan of the dynamic secret is called “time to live” or TTL). This unique credential is returned to the requester along with a unique identifier that allows the secret to be audited, located, and revoked early if supported.

Every application instance has a different credential and can have a different TTL. A lease is created for each dynamic secret, and the lease contains information such as TTL, renewability, and more. Once the lease expires, the secret is revoked and no longer valid. Prior to that, if the lease allows it, the secret can be renewed for another predetermined length of time.

»When to use dynamic secrets

Dynamic secrets are particularly useful for ephemeral workloads in environments with stringent security requirements, such as:

• Cloud environments
• Distributed systems
• Microservice architectures

They are also ideal for time-bound workloads or temporary access such as:

• Terraform runs
• GitHub Actions
• Kubernetes CronJobs
• Temporary access to troubleshoot a faulty system
• Any other use cases with a clear beginning and end

Generally, you should use dynamic secrets for critical, production systems (e.g. databases, cloud services) where you want to provide granular time-bound access to resources. For example, using dynamic secrets in your CI/CD workflow means the pipeline can request a temporary credential with permission to perform specific tasks, which expire once the pipeline execution completes. Dynamic secrets, like auto-rotated secrets, can also be used to help meet compliance standards such as PCI DSS and SOC, but when shorter-lived, ephemeral secrets are required.

»The difference between rotated vs. dynamic secrets

Dynamic secrets are suited for time-bound workloads like batch jobs to a database, access to critical resources in cloud service, or CI/CD executions. They are also unique to each workload whereas auto-rotated secrets are often shared with multiple workloads. Auto-rotating secrets are suited for longer-lasting workloads that need more stability in their connection but still need to be rotated, like an application needing consistent access to a database to handle user requests or applications needing consistent access to a credential to function properly.

Another key difference is that dynamic credentials are unique to a single workload (like an application instance, CI/CD execution, Terraform run, etc.), and each set of credentials can be revoked irrespective of other running applications. Because of this, dynamic secrets can provide the most secure posture as they greatly reduce the potential for attack if one of these secrets gets exposed. Auto-rotated secrets, as explained earlier in the post, can be used by multiple workloads, and have a higher impact when revoked.

If supported by the issuing service, the dynamic secrets can be bound to properties of the caller, such as IP address. This means that if a credential is leaked, it is traceable back to the workload that requested it, giving additional traceability to forensic investigations when compared to auto-rotated secrets.

Dynamic secrets cater to the dynamic nature of modern IT environments, while auto-rotated secrets provide automated support for longer running workloads. Together, they form a robust and comprehensive approach to safeguarding sensitive information and mitigating security risks effectively.

»Caveats and considerations

While this blog proposes suitable use cases for auto-rotated and dynamic secrets based on each type’s unique properties, this does not mean that dynamic secrets can’t power static web servers or that auto-rotated secrets can’t power GitHub Actions. The proposed use cases simply provide examples where the unique properties of each strategy are most effective.

With that in mind, here are some considerations from a developer perspective if you plan to use auto-rotated or dynamic secrets for use cases outside of the general guidelines provided above.

If you decide to use dynamic secrets for long-lasting workloads, the target application logic needs to:

• Request new credentials at runtime when existing credentials are about to expire, or
• Have the ability to gracefully boot new workload instances and shut down old ones when credentials are about to expire.

This becomes important if communication with your secrets manager is lost due to an outage, because workloads won’t be able to request new credentials, and existing credentials with a predetermined TTL will expire, causing application outages as well.

If you decide to use auto-rotated secrets for time-bound workloads:

• Remember auto-rotated credentials are not bound to the consumer’s lifecycle as are dynamic secrets; they may rotate mid-execution. This is not an issue if you have more than one valid credential available as part of the secret rotation. This is also not unique related to time-bound workloads but using rotated secrets in general.

»Key benefits of using auto-rotated and dynamic secrets

Organizations can effectively address a broader range of security requirements and operational challenges by incorporating both dynamic secrets and secret auto-rotation into their secrets management practices. The fewer long-lived static secrets you use, the better. Manual secret rotation means there’s no guarantee that secrets will be changed in a timeframe concordant with the appropriate threat model, which leaves more openings for threat actors.

The following are some key benefits of incorporating auto-rotated and dynamic secrets.

• Decreased operational overhead: Manually managing secrets is cumbersome and time-consuming, so automating rotation and enabling dynamic secrets takes the burden of individual rotations off of developers and operations.
• Reduced risk: Reducing long-lived secrets reduces the risks and costs associated with secret exposure.
• Enhanced auditability and visibility: Better tracking and monitoring of secret usage and lifecycle helps identify abnormal or malicious behavior.
• Increased scalability and flexibility: Supporting more automated types of secrets and environments helps organizations quickly adapt to changing business and security needs. It also allows teams to scale up the number of applications they support.

»Learn more

HashiCorp’s security lifecycle management (SLM) products provide multiple ways for you to start using dynamic and auto-rotating secrets and reduce your risk of downtime and breach.

HashiCorp Vault is a widely-used and popular solution for secrets management, battle-tested by critical institutions and Fortune 500 enterprises. HCP Vault Dedicated provides a cloud-hosted alternative to Vault’s self-managed product and offers the same dynamic and auto-rotating secret capabilities. HCP Vault Secrets is a multi-tenant SaaS platform providing the fastest way to get up and running with Vault. HCP Boundary is a fully-managed, cloud-based product that enables secure connections using dynamic credentials to remote hosts and critical systems across cloud and on-premise environments.