There’s a certain panic that follows a private key being committed to a repository. With developers juggling more responsibilities than ever before, it’s only natural that human error can lead to vulnerabilities. The solution: designing a system that prevents this from happening in the first place.
Secrets—such as private keys, API tokens, and certificates—are increasingly prevalent with the popularity of cloud computing. Whenever EC2 talks to Stripe or a database, secrets authorize access. However, because secrets are long-lived by default, they provide a lucrative attack surface for hackers.
Many companies still use manual rotation for secrets despite the risks. This is particularly dangerous if they’re discreetly stolen: The compromised credential may remain active for months before detection, leaving an open window for hackers.
Two common approaches to solving this problem include automated secret rotation and dynamic secrets.
Automated Secret Rotation
Gaining access to secrets is an ideal scenario for a hacker. Once compromised, these credentials can allow for unlimited authorization to sensitive computing resources.
One approach to mitigating this problem is to manually rotate secrets after predetermined intervals. In theory, this limits each credential’s useful lifespan, but in practice, it’s cumbersome and leaves room for human error. Manual rotation places an unnecessary burden on developer time and suffers from poor adherence across the hundreds of microservices in modern stacks, ultimately leaving secrets valid far longer than intended.
Instead, we can automate secret rotation. With automated secret rotation, developers save time, human error is eliminated, and shorter secret lifetimes become feasible.
Rotated secrets work well for long-running services that maintain persistent connections to resources, such as databases or external APIs. These use cases benefit from stable credentials that can be rotated on a predictable schedule, maintain persistent identity in a simple way, and avoid disrupting ongoing operations.
How does automated secret rotation work?
Services requesting protected resources are updated to call a secrets provider, which provides the valid secret. When it’s time for secrets to rotate, the secrets provider automatically generates and stores the new secret, then later revokes the old secret.
This approach prevents downtime by always maintaining two valid secrets for a given service. When a secret is rotated, the current secret (Secret 1) remains valid but is marked ‘inactive,’ and the newly provisioned secret (Secret 2) is marked ‘active.’ Both are valid, but only one is marked ‘active.’
When secrets are rotated again, Secret 2 is marked ‘inactive’ but remains valid, and Secret 1 is finally revoked. A new secret is provisioned (Secret 3) and marked ‘active.’
Automated secret rotation saves developer time. But it also improves an organization’s security; because automated secret rotation is programmatic, shorter credential lifetimes are feasible with zero risk of downtime.
However, automated secret rotation is only one strategy for automating the secrets lifecycle. A more robust solution, which is applicable in choice scenarios, is dynamic secrets.
Dynamic Secrets
Dynamic secrets are credentials generated just in time for specific data access.
This is a fundamentally different approach to identity management. Rather than relying on long-lived credentials, this approach generates fresh secrets on demand for each request to a specific resource, with a defined TTL. This tight scoping enables more granular access control than traditional secrets while achieving the zero standing privileges principle—ensuring no entity maintains persistent permissions.
There are some material benefits to this approach. First, it increases security by minimizing blast radius and creating a moving target for an attacker: A compromised secret is unlikely to be valid by the time an attacker uses it, and it would generally grant less access than a traditional secret. Second, dynamic secrets improve auditability—making it possible to monitor the actions performed by any particular token. Finally, dynamic secrets are more scalable, as no coordination is needed across rotation windows.
Dynamic secrets excel with short-lived, ephemeral workloads like CI/CD pipelines and serverless functions. These workloads naturally align with the dynamic secrets model since they execute briefly and terminate, making on-demand credential generation more efficient than managing long-lived secrets that persist beyond the workload’s lifetime.
Requirements for dynamic secrets implementation
There are some considerations to determine whether dynamic secrets are ideal:
- Infra capabilities: Does the protected resource support automatic provisioning of users and permissions? If not, dynamic secrets can’t be generated. External APIs such as Stripe don’t support dynamic secrets, while internal infrastructure, including AWS, Oracle, or Kubernetes, allows for a fairly straightforward implementation.
- Billing: Does your protected resource charge per user created? This would make dynamic secrets extremely expensive and likely infeasible.
- Performance: Is your protected resource latency-sensitive? If so, the additional latency from provisioning dynamic secrets (10-100ms) may make this approach infeasible.
How do dynamic secrets work?
First, protected resources must support secrets that expire.
For each request to that protected resource, the calling service generates a dynamic secret using a secrets management provider. The secrets management provider then provisions the secret and sends it back to the calling service, which now has access to the protected resource until the TTL expires.
In conclusion, dynamic secrets are generated on demand and are only valid for a short period of time. While this requires more upfront setup and is not applicable in all use cases, dynamic secrets offer more security and scalability.
Comparing Automated Secrets Rotation With Dynamic Secrets
Let’s compare the different approaches to improving the security of secrets:
| Criteria | Automated Secrets Rotation | Dynamic Secrets |
|---|---|---|
| Security | Higher risk. Credentials are valid for a longer period of time. | Lower risk. Credentials are valid for a shorter period of time. |
| Lifespan | Higher. Credentials are valid until rotation period. | Lower. Credentials are valid until their TTL. |
| Implementation Effort | Low. Works easily with existing systems using secrets. | Moderate. Requires custom setup, though can be mitigated by templates/prebuilt workflows. On the other hand, use cases like self-serve database access can be enable easily. |
| Scalability | Less scalable. Secrets need to be stored and schedules tracked. | More scalable. Secrets can be generated on the fly. |
| Auditability | Depends. Identity is persistent and can be monitored over time. | Depends. Per-access identity means easy to track what permissions were given and when. |
| Performance Impact | Minimal impact, only during rotation | Moderate, 10-100ms per access |
| Compatibility | High. Most systems support secrets and automatic rotation of secrets. | Lower. Service must support automatic provisioning of users and permissions. Infisical provides integrations for systems like Kubernetes and more. |
| Compliance | Depends. Better for frameworks that require persistent identity. | Depends (see other column) |
Choose dynamic secrets for:
- Short-lived, ephemeral workloads such as CI/CD or serverless functions
- High-security environments that benefit from low credential lifetimes
- Compatible infrastructure that supports automatic provisioning of users and permissions
Choose automated secrets rotation for:
- Longer-running workloads, such as applications looking for constant access to a database
- Performance critical applications, as dynamic secret generation introduces more latency than rotated secrets (generally 200-800ms per credential generation vs. ~1ms for cached static credentials)
Final Thoughts
Automated secrets rotation and dynamic secrets reduce security risks, eliminate developer overhead, and improve scalability.
They also require implementation effort. Infisical makes it easy to set up both with prebuilt templates. Try our automated secrets rotation template for AWS here, or our dynamic secrets template for GCP here.
