Securely store secrets for CI/CD pipelines

CI/CD pipelines are among the highest-value targets in an organization's attack surface. Most CI/CD pipelines require access to secrets for access cloud providers, databases, container registries, and deployment targets. When you hard code these secrets into your pipeline, or store them in the CI tool's secret store, you create security risks and operational overhead.

The consequences of storing secrets in the CI/CD pipeline or CI tool's secret store extend beyond secrets sprawl. Compromised pipelines can lead to data breaches, ransomware attacks, and supply chain attacks. A static credential stored in a CI platform's secret store needs to be manually rotated, has limited audit trails, and cannot be revoked without manual intervention.

HashiCorp Vault addresses these concerns by serving as the single control plane for pipeline credentials: pipelines authenticate using their existing platform identity, receive a short-lived token scoped to only the secrets they need. The token expires at a defined TTL, does not require credential rotation, and lets you eliminate shared static secrets between pipelines.

This collection provides guidance and resources for securing popular CI/CD platforms with Vault, and highlights common authentication and secrets management anti-patterns.

How pipeline authentication works

Every CI/CD platform provides some form of workload identity — a JWT, a Kubernetes service account token, a TLS certificate, or a platform-issued OIDC token. Vault's auth methods validate these identities without requiring any pre-provisioned credential to be injected into the pipeline. The authentication flow is similar regardless of platform:

1. The pipeline presents its identity to Vault
2. Vault validates the identity and checks it against a role definition
3. Vault issues a short-lived token, scoped to a policy for that role
4. The pipeline uses the token to retrieve the required secrets
5. The token expires at the defined TTL; no cleanup required

You define your security controls in a role. The role binds the authentication to a specific identity (service account, project, certificate CN, or CIDR) and a specific policy. Eliminating the need for pre-provisioned secrets eliminates common CI/CD pipeline anti-patterns, lets you manage roles on a per-pipeline basis, and eliminates the risk of shared secrets between pipelines.

Choosing an authentication method

The right auth method depends on where your pipeline infrastructure runs and what identities are already available:

Extend CI/CD pipeline security with HCP Vault Radar

Before implementing Vault-based secrets management, you can use HCP Vault Radar to scan existing pipeline definitions stored in source code repositories. HCP Vault Radar helps you identify secrets that may already be exposed like hardcoded API keys, tokens in environment variable definitions, and usernames and passwords.

HashiCorp resources

• Read the Available authentication methods documentation to choose the right Vault auth method for your CI/CD platform.
• Read Five best practices for secrets management for HashiCorp's guidance on building a secure secrets management strategy.

Next steps

The following pages cover authentication patterns, integration options, and security considerations for each supported CI/CD platform:

• CI/CD anti-patterns
• CI/CD Dynamic and Static secrets
• Azure DevOps
• CircleCI
• GitLab
• GitHub Actions
• Jenkins
• TeamCity
• Tekton