CI/CD security considerations

There are several security considerations you need to align with your organizational risk tolerance and operational constraints when designing your CI/CD secrets management strategy. The following are some best practices to consider:

• Workload identity isolation: Every distinct pipeline workload should have its own identity boundary and its own Vault role. Depending on the platform, that identity might be a Kubernetes service account, a cloud instance role, an OIDC token subject, or a platform service connection. Reusing one identity across unrelated pipelines creates a lateral movement path if one workload is compromised.
• Policy least privilege: Vault policies for CI/CD roles should grant read access only to the specific secret paths that a pipeline needs. Wildcard paths such as secret/ci/* are convenient but expand the blast radius of a compromised pipeline token to the entire subtree.
• Token TTL alignment: Pipeline token TTLs should slightly exceed the expected maximum job duration, not a round number such as 24 hours. A token that outlives the job it was issued for becomes a lingering credential.
• Bootstrap credential minimization: If a platform cannot present a native workload identity and must bootstrap with AppRole, TLS material, or another intermediate credential, keep that material short-lived, single-use where possible, and tightly scoped. Response wrapping and just-in-time delivery are safer than storing reusable bootstrap secrets in pipeline configuration.
• Variable and log exposure: Secrets passed through environment variables, temporary files, or pipeline variables can be exposed through debug output, subprocesses, crash data, or artifact publication. Treat pipeline logs as durable records, use each platform's secret-masking features where available, and design jobs so they do not print secret values.
• JWT and workload role constraints: For JWT or other federated auth methods, configure the most specific role constraints possible. Depending on the platform, that can include bound_claims, bound_audiences, bound_subject, cloud principal bindings, namespace restrictions, or service account bindings. An unconstrained role allows more workloads than intended to authenticate to Vault.
• Multi-team isolation boundaries: In multi-team environments, use separate Vault roles, auth mounts, policies, and when available, namespaces or separate trust domains to isolate teams from one another. Shared CI/CD infrastructure should not imply shared secret access.

Next steps

Refer to the product-specific documentation for your CI/CD platform to see how to plan and design your secrets management strategy in your environment.