CI/CD pipelines routinely need access to sensitive credentials (deployment keys, API tokens, database passwords) — this guide covers securely managing these secrets throughout your pipeline.
Why This Is a Distinct Concern from General Secrets Management
See How to Manage Environment Variables and Secrets on a VPS for the general principles — CI/CD adds specific considerations: secrets need to be available to automated, sometimes third-party-triggered processes, without ever appearing in logs or being exposed to untrusted pipeline code.
Using Your CI Platform's Built-In Secrets Management
GitHub Actions, GitLab CI, and most CI platforms provide encrypted secrets storage specifically designed for this purpose — use these native mechanisms rather than hardcoding credentials in pipeline configuration files, which get committed to version control.
GitHub Actions Secrets Example
jobs:
deploy:
steps:
- run: ./deploy.sh
env:
DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}Secrets configured in repository settings are injected as environment variables at runtime, never appearing in the committed workflow file itself.
Never Log Secret Values
echo "Deploying with key: $DEPLOY_KEY" # NEVER do thisMost CI platforms automatically mask known secret values in logs, but this protection isn't foolproof (particularly if a secret value is transformed/encoded before appearing in output) — be deliberate about never explicitly logging secret values.
Restricting Secret Access by Environment/Branch
Production deployment secrets shouldn't be accessible to every pipeline run — most platforms support environment-scoped secrets, letting you restrict production credentials to only runs targeting production (typically the main/release branch), not every feature branch build.
Using a Dedicated Secrets Manager for Complex Setups
For more sophisticated needs (rotation, audit logging, fine-grained access), consider a dedicated secrets manager (see Docker Secrets Management: Handling Sensitive Data in Containers for the underlying concept) that your CI pipeline retrieves credentials from at runtime, rather than storing long-lived secrets directly in CI platform configuration.
Limiting Secret Scope (Least Privilege)
See How to Implement the Principle of Least Privilege on a Linux VPS — a deployment credential used by CI should have only the minimum permissions genuinely needed for deployment, not broad administrative access "just in case."
Rotating CI/CD Secrets Regularly
See How to Rotate Secrets and Credentials on a Schedule — CI/CD credentials are a particularly attractive target (broad access, often long-lived) and deserve regular rotation as part of your overall credential hygiene.
Auditing Who Can View/Modify Secrets
Restrict who has permission to view or modify CI/CD secret configuration — most platforms support role-based access for this specifically; not every team member needs this level of access.
Securing Third-Party Actions/Plugins
See How to Harden a VPS Against Supply Chain Attacks — a compromised or malicious third-party CI action/plugin with access to your secrets is a genuine supply chain risk; pin to specific verified versions rather than always using the latest, unreviewed version of external actions.
Common Errors
Secret accidentally exposed in a pull request from a fork — most CI platforms restrict secret access for pull requests from external forks by default as a security measure; verify this protection is genuinely active for your specific pipeline configuration.
Continue Reading
- How to Manage Environment Variables and Secrets on a VPS
- CI/CD Pipeline Security Best Practices
- How to Rotate Secrets and Credentials on a Schedule
Browse more articles in DevOps & CI/CD.
