Secrets Management in CI/CD Pipelines

1. Purpose

To define a standard operating procedure (playbook) for managing sensitive values (“secrets”) in CI/CD pipelines, such as API keys, database credentials, tokens, and cryptographic keys. The objective is to reduce the risk of accidental exposure and unauthorized access.

2. Scope

This playbook applies to all DevSecOps engineers, platform teams, and application developers managing continuous integration and deployment processes using tools like GitHub Actions, GitLab CI/CD, Jenkins, and HashiCorp Vault.

3. Definitions

• Secret: Any sensitive information such as passwords, tokens, or private keys.
• Vault: A secure storage mechanism for secrets (e.g., HashiCorp Vault, AWS Secrets Manager).
• Scoped Secrets: Secrets limited in access to specific environments or contexts.
• Ephemeral Secrets: Short-lived credentials dynamically generated at runtime.

4. Roles & Responsibilities

• DevSecOps Team: Maintains vaulting infrastructure, enforces policies, and audits usage.
• Developers: Consume secrets securely via CI/CD and report misconfigurations or exposures.
• Security Team: Oversees access controls and ensures compliance with regulatory standards.

5. Tooling Overview

• GitHub Actions: Use encrypted secrets and environment-level protection with OIDC integration.
• GitLab CI: Use masked, protected CI/CD variables and Vault integration.
• Jenkins: Use the Credentials Plugin and secure pipeline libraries.
• Vault Tools: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.

6. Implementation Steps

1. Identify secrets required by the pipeline or application (e.g., DB credentials, tokens).
2. Classify secrets based on sensitivity and environment (dev, test, prod).
3. Store secrets in a secure vault or encrypted secret manager.
4. Configure CI/CD to fetch secrets securely (OIDC, short-lived tokens preferred).
5. Inject secrets at runtime via environment variables or secret mounting (never in code).
6. Implement automatic rotation and expiration policies where possible.
7. Audit usage and access logs on a regular basis.

7. Best Practices

• Do not store secrets in source control (even encrypted files).
• Use fine-grained IAM policies to control access to secrets.
• Prefer environment-specific secrets over global values.
• Use ephemeral credentials issued through identity federation where possible (OIDC, IAM roles).
• Restrict write access to secret storage platforms.
• Enable alerting on access anomalies or secrets misconfiguration.

8. Example Integration: GitHub Actions + AWS OIDC

This example demonstrates a secure pattern for CI/CD pipelines to access AWS secrets using OIDC-based federation.

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubOIDCRole
          aws-region: us-east-1

      - name: Access secure secret
        run: aws ssm get-parameter --name "/app/prod/db_password" --with-decryption
    

9. Diagrams

12. References

• GitHub Actions Secrets Guide
• GitLab CI/CD Variables
• Jenkins Credentials Documentation
• HashiCorp Vault Documentation
• AWS Secrets Manager