Dynamic Secret Injection in CI/CD: When to Use It and How to Implement It

Not every pipeline credential benefits equally from dynamic injection. The decision framework considers three factors: the privilege level of the credential, the blast radius if the credential is compromised, and the rotation burden of managing it statically.

Use dynamic secrets when:

• The credential provides write, delete, or administrative access to a production system (production database, production cloud account, production Kubernetes cluster)
• The credential, if compromised, would allow an attacker to access customer data, financial systems, or production infrastructure
• The credential is used in a pipeline that runs frequently (multiple times per day), creating high re-use of the same static credential and a long exposure window
• Compliance requirements mandate credential rotation at a frequency shorter than the operational tolerance for manual rotation (NIST SP 800-57 recommends 90 days max for symmetric keys in production -- manual rotation at that frequency is feasible but error-prone)

Static secrets with automated rotation are sufficient when:

• The credential provides read-only access to non-production systems (a test database, a staging artifact store)
• The blast radius of compromise is limited (a compromised credential can only read test data, not modify production)
• The credential is used in a low-frequency pipeline where re-use risk is minimal
• The target system does not support dynamic credential generation (some legacy systems can only accept static username/password authentication)

Zero-credential pipelines (best practice for cloud deployments): For AWS, GCP, and Azure deployments from GitHub Actions, GitLab CI, or CircleCI, the OIDC federation approach eliminates stored credentials entirely. The pipeline authenticates using a short-lived OIDC token generated by the CI/CD platform, which is exchanged for a cloud platform IAM token. No credential is stored anywhere -- the pipeline identity is verified by the CI/CD platform's signing of the OIDC token.

GitHub Actions OIDC federation with AWS, GCP, and Azure is the most impactful dynamic secret approach because it eliminates stored cloud credentials entirely rather than replacing one credential type with another.

How it works: GitHub generates a short-lived OIDC token for each workflow run. The token contains claims about the workflow: the repository name, the branch, the workflow name, the triggering event. The CI/CD platform signs this token with its private key. Your cloud provider verifies the signature using GitHub's published JWKS endpoint and, if the token's claims match your trust policy, issues a short-lived cloud IAM token.

AWS implementation. Create an IAM OIDC Identity Provider in AWS for token.actions.githubusercontent.com. Create an IAM role with a trust policy that permits assumption by the OIDC provider with conditions matching your repository name and branch: StringLike: {"token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"}. In the GitHub Actions workflow, use the aws-actions/configure-aws-credentials action with role-to-assume pointing to the IAM role ARN and aws-region set. No AWS access key or secret key is stored anywhere in GitHub secrets.

GCP implementation. Create a Workload Identity Pool and Provider in GCP for the GitHub Actions OIDC endpoint. Map GitHub token claims to Google Cloud identities. Bind the Workload Identity user to a service account with the required permissions. In the workflow, use google-github-actions/auth with workload_identity_provider and service_account parameters.

Azure implementation. Use Azure Federated Credentials on an Azure App Registration. Configure a federated credential that trusts token.actions.githubusercontent.com for the specific repository and entity (branch, environment, or tag). In the workflow, use azure/login@v1 with client-id, tenant-id, and subscription-id (no client-secret required when using federated credentials).

HashiCorp Vault's dynamic secrets engine generates database credentials on-demand with configurable TTLs. Each credential generation creates a unique username and password that Vault manages the lifecycle of -- rotating before TTL expiration and revoking at the lease end.

Vault database dynamic secrets setup:

1. Enable the database secrets engine: vault secrets enable database
2. Configure a database connection: vault write database/config/prod-postgres plugin_name=postgresql-database-plugin connection_url="postgresql://{{username}}:{{password}}@prod-db:5432/appdb" allowed_roles="deploy-role" username="vault-admin" password="..."
3. Create a role that defines the credential lifetime and SQL permissions: vault write database/roles/deploy-role db_name=prod-postgres creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}' IN ROLE app_readonly;" default_ttl="15m" max_ttl="1h"
4. The pipeline authenticates to Vault (using the OIDC/JWT auth method bound to the pipeline's identity token), reads vault read database/creds/deploy-role, and receives a unique username and password valid for 15 minutes.

Vault authentication from CI/CD: Use the Vault JWT/OIDC auth method with the CI/CD platform's OIDC token as the authentication mechanism. This makes the pipeline's Vault authentication itself dynamic -- the pipeline does not have a static Vault token stored in GitHub secrets. The JWT auth method validates the CI/CD OIDC token and issues a Vault token scoped to the specific policy for the pipeline's role.

For pipelines that need a static Vault token as a bootstrap credential: Use a short-lived approle credential (role_id + secret_id) stored in GitHub secrets, with secret_id rotation configured in Vault. The role_id is not sensitive (it is public); the secret_id is sensitive but is a single-use token that Vault can rotate automatically.

For AWS-hosted pipelines deploying to AWS-hosted databases, the AWS IAM database authentication feature provides dynamic credential generation without Vault. RDS and Aurora support IAM authentication, which generates database tokens from IAM credentials rather than storing database passwords.

Setup for AWS IAM database authentication:

1. Enable IAM authentication on the RDS instance or Aurora cluster.
2. Create an IAM policy that allows rds-db:connect for the specific DB instance and database user.
3. Attach the policy to the IAM role assumed by the CI/CD pipeline (via OIDC federation as described in Approach 1).
4. In the pipeline, use aws rds generate-db-auth-token to generate a 15-minute authentication token using the pipeline's current IAM credentials. The token is used as the database password in the connection string.

This approach eliminates the database password entirely for AWS-hosted databases. The database authentication uses the pipeline's IAM identity, which is already dynamic (via OIDC federation), making the database credential chain fully dynamic with no stored secrets.

For non-AWS databases in AWS pipelines: AWS Secrets Manager supports automatic rotation for RDS, Redshift, DocumentDB, and custom secrets with Lambda rotation functions. While not strictly dynamic secrets (the credential is fetched at pipeline start rather than generated uniquely per run), automatic rotation with 30-day intervals reduces the credential lifetime significantly versus manual rotation. This is the "static secrets with automated rotation" approach from the decision framework -- appropriate for lower-privilege or legacy-system credentials.

Dynamic secrets reduce the risk of credential compromise but do not eliminate it. A pipeline with a 15-minute TTL credential can still be used maliciously during those 15 minutes if the pipeline is triggered by a malicious actor or if the credential is extracted during the pipeline run.

Vault audit logging. Enable Vault audit logging for all credential generation events. Each dynamic credential generation records: the authentication method used, the policy that permitted the generation, the role or path accessed, the issuing IP address, and the generated credential identifier (without the secret itself). Alert on credential generation from unexpected authentication sources (IP addresses outside your CI/CD runner network, unexpected auth method usage) and on credential generation volume spikes (more generations in an hour than typical for the repository).

AWS CloudTrail for OIDC role assumptions. Every time a GitHub Actions workflow assumes an AWS IAM role via OIDC, CloudTrail records: AssumeRoleWithWebIdentity with the repository name, workflow name, and assumed role ARN. Alert on assumptions from unexpected repositories (a repository that should not have access to the production deployment role), unexpected workflow names (a new workflow file in the repository that was not in the allowlist), and assumptions outside normal business hours for your CI/CD workflows.

Anomaly detection for dynamic credential usage pattern. If a pipeline typically generates one set of database credentials per run and runs 10 times per day, an anomaly is 50 credential generations in one hour. Configure a SIEM alert or CloudWatch metric that fires when dynamic credential generation volume exceeds 2 standard deviations from the rolling 7-day average. Volume spikes may indicate a pipeline running in an abnormal loop, a build farm misconfiguration, or a compromised workflow being triggered repeatedly.

Migrating from static secrets to dynamic injection does not require a big-bang cutover. A staged migration reduces risk and allows validation at each step.

Stage 1: Inventory and classify all pipeline secrets. List every secret currently stored in your CI/CD platform (GitHub Actions secrets, GitLab CI variables, Jenkins credentials). Classify each by the decision framework: which should move to dynamic injection (high-privilege production credentials), which should stay as static with automated rotation (low-privilege test credentials), and which can be eliminated (unused secrets from decommissioned integrations).

Stage 2: Implement zero-credential cloud access first. The OIDC federation approach for cloud deployments is the highest-impact, lowest-disruption migration. The change: replace AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY GitHub secrets with IAM OIDC trust configuration and the configure-aws-credentials action. This requires no changes to the pipeline's downstream operations -- the workflow still has valid AWS credentials at the point where it needs them. Test in a staging workflow before migrating the production deployment workflow.

Stage 3: Migrate highest-privilege database credentials to dynamic generation. After cloud access is dynamic, migrate production database credentials to Vault dynamic secrets or AWS IAM database authentication. Run parallel validation: the same integration tests passing with both the old static credential and the new dynamic credential before removing the static credential from GitHub secrets.

Stage 4: Implement automated rotation for remaining static secrets. For secrets that stay as static (legacy systems, third-party APIs without OIDC support), implement automated rotation via Vault secret sync, AWS Secrets Manager rotation, or a custom rotation Lambda. Rotation should occur at a maximum 90-day interval with automatic propagation to the CI/CD platform's secret store.