Well-Architected Framework
Dynamic and static secrets in CI/CD
You can use both dynamic and static secrets in your CI/CD pipelines, depending on your security requirements and workflow.
Static secrets are conventional, long-lived credentials that you manually create and store. Static secrets remain unchanged until explicitly updated or destroyed. In contrast, dynamic secrets are created on-demand when a client requests them. Each client request for dynamic secrets generates a new set of credentials. Dynamic secrets also expire after a specified time.
| Aspect | Dynamic Secrets | Static Secrets |
|---|---|---|
| Creation | Generated by Vault on-demand | Manually created and stored |
| Lifecycle | Automatic expiration/revocation | Manual rotation/revocation |
| Lifespan | Short-lived (minutes to hours) | Long-lived (until changed) |
| Uniqueness | Unique per request | Shared across users/systems |
| Auditing | Detailed per-request tracking | Limited audit capabilities |
| Risk | Lower (minimal exposure time) | Higher (persistent credentials) |
You can use HashiCorp Vault to manage both dynamic and static secrets in your CI/CD pipelines. Vault provides a unified interface for managing secrets, enabling you to enforce consistent security policies across your workflows.
Dynamic secrets
When you request access to a secret, Vault generates a dynamic secret on demand. Dynamic secrets don't exist until a user or system reads them, eliminating the risk of theft or unauthorized use by another client. Vault's built-in revocation mechanisms allow it to revoke dynamic secrets after use, minimizing the lifespan of the secret.
Vault supports a range of secret engines that integrate with services like CI/CD tools to generate dynamic credentials as needed. These secrets engines are plugins to external services, such as AWS, Azure, GCP, Kubernetes, databases, and more. After enabling a secrets engine and authenticating Vault to an external resource, users can request credentials from Vault to access the external resource.
Consider a CI/CD pipeline job that requires retrieving an object from Amazon S3. Instead of using hard-coded AWS credentials in code, plaintext files, or CI/CD environment variables, the pipeline can authenticate to Vault using one of the supported authentication methods. Once authenticated, Vault issues temporary credentials to the CI/CD job that automatically expire when the pipeline completes its task. The pipeline task can use these temporary credentials to retrieve the object from S3 securely.
The following are benefits of using dynamic secrets in CI/CD pipelines:
- Reduce risk: No long-lived credentials that can become compromised
- Automatic cleanup: No manual revocation required
- Unique tracking: Each credential tied to specific access request
- Better auditing: Clear audit trail of credential usage
HashiCorp resources:
- Database credential rotation
- Dynamic secrets for AWS authentication for S3 access
- Understand dynamic secrets
- SSH Secrets engine: One-time SSH password
- Schedule-based static role rotation
External resources:
- From Vulnerabilities to Vault: How We Stopped Hard-coding Secrets and Started Using HashiCorp Vault
- External Secrets Operator Vault Dynamic Secret
- GitOps Secrets with Argo CD, HashiCorp Vault and the External Secret Operator
- Use HashiCorp Vault's Dynamic Secrets
Static secrets
Vault enables you to manage static secrets with the KV (key/value) secrets engine. After you enable a KV secrets engine in Vault, users can create static key/value secrets, like passwords, API keys, and certificates. CI/CD pipelines can authenticate with Vault, and retrieve these secrets instead of using secrets stored in code, files, or environment variables.
The following are common use cases for static secrets in CI/CD pipelines:
- Third-party API keys: External service credentials
- Shared certificates: SSL/TLS certificates used by multiple services
- Legacy systems: Systems that can't use dynamic secrets
- Configuration values: Non-dynamic configuration data
Consider a CI/CD pipeline job that requires access to a Google service. Vault can use the KV secrets engine to store the Google API key as a static secret. When the pipeline runs, the job authenticates with Vault and retrieves the API key, allowing secure access to the Google service without exposing sensitive credentials in code or configuration files.
HashiCorp resources:
Next steps
In this overview of dynamic and static secrets in CI/CD, you learned that you can use both types of secrets depending on your security requirements and workflow. Dynamic secrets are generated on-demand and have a short lifespan, while static secrets are long-lived credentials that you manually create and store. You can use HashiCorp Vault to manage both types of secrets in your CI/CD pipelines.
In this section of managing CI/CD secrets, you the learned about dynamic and static secrets, and which type to use in your use-case. CI/CD dynamic and static secrets is part of the Secure systems pillar.