Secrets Management in CI/CD

Secrets management is the discipline of storing, distributing, rotating, and auditing sensitive credentials — API keys, database passwords, deployment tokens, TLS certificates — in a way that makes them available to the pipeline at runtime without ever exposing them in source code, log files, or build artifacts. A pipeline that cannot access credentials cannot deploy. A pipeline that handles credentials carelessly becomes an attack surface. Secrets management is the practice that threads this needle: credentials are available exactly where they are needed, and nowhere else.

Secrets vs Configuration — A Critical Distinction

Not all per-environment values are secrets. A secret is a value whose exposure would cause harm — a private key, an authentication token, a database password. A configuration value is a value that varies per environment but carries no inherent risk if seen — a database hostname, a feature flag state, a log level. Treating these two categories identically — storing everything as a secret — produces an unmanageable secret store and obscures which values actually need protection. Treating configuration as secrets adds management overhead for no security benefit.

GitHub Secrets — Built-In Secret Storage

GitHub Actions provides encrypted secret storage at three levels: repository secrets (available to all workflows in a repository), environment secrets (available only to jobs targeting a specific environment), and organisation secrets (available to selected repositories across an organisation). Environment-scoped secrets are the most important for CI/CD pipelines — they ensure that production credentials are only accessible to jobs that explicitly target the production environment, and staging credentials to staging jobs.

GitHub secrets are encrypted at rest using libsodium sealed boxes, masked in logs automatically — any value that matches a secret is replaced with *** in the workflow output — and are never exposed to the runner's environment in a way that allows them to be read by other processes. They are injected as environment variables at the step level and are not accessible between jobs unless explicitly passed as outputs.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production              # Only production-scoped secrets are available here

    steps:
      - name: Deploy to production
        env:
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}         # Injected at step level only
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}       # Masked in all log output
        run: |
          ./deploy.sh \
            --db-password "$DB_PASSWORD" \
            --token "$DEPLOY_TOKEN"

      - name: Notify on success
        env:
          SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}     # Different secret, same pattern
        run: |
          curl -X POST "$SLACK_WEBHOOK" \
            -d '{"text": "Production deployment succeeded"}'

  # This job has NO access to production secrets — different environment scope
  test:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - run: npm test
        env:
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}         # This is the STAGING DB_PASSWORD
                                                          # not the production one

External Secrets Managers — Vault, AWS Secrets Manager, and Beyond

GitHub Secrets is sufficient for most pipelines, but larger organisations often centralise secret management in a dedicated secrets manager — HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, or Azure Key Vault. These platforms offer capabilities that GitHub Secrets does not: fine-grained audit logs of every secret access, dynamic secrets that are generated on demand and expire automatically, secret versioning with rollback, and cross-platform availability for secrets used outside of GitHub Actions.

Dynamic secrets are one of the most powerful features of dedicated secrets managers. Rather than storing a long-lived database password, Vault generates a unique, time-limited credential for each pipeline run — valid for 15 minutes, then automatically revoked. If the credential is leaked, the attacker has a narrow window before it expires. This is categorically more secure than rotating a static password on a schedule, and it eliminates the class of incident where a leaked credential remains valid for months because nobody noticed it was compromised.

OIDC and Keyless Authentication — Eliminating Long-Lived Credentials

The most secure secret is one that does not exist. OpenID Connect (OIDC) is a protocol that allows GitHub Actions to authenticate directly to cloud providers — AWS, GCP, Azure — without storing any long-lived credentials in GitHub Secrets at all. Instead, the pipeline requests a short-lived token from the cloud provider at runtime, proving its identity through GitHub's OIDC token. The cloud provider validates the token and grants the permissions defined in a trust policy.

The security advantage is significant. There is no static AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY stored anywhere — nothing to rotate, nothing to leak, nothing to expire and break pipelines at 3am. The trust policy on the cloud provider side defines exactly which repositories, branches, and environments can assume which roles. A compromised repository cannot use OIDC to escalate to a role it was not explicitly granted. This pattern is now the recommended approach for all AWS, GCP, and Azure deployments from GitHub Actions.

permissions:
  id-token: write                        # Required for OIDC token request
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/GitHubActionsDeployRole
          aws-region: eu-west-1
          # No AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY stored anywhere
          # GitHub requests a short-lived token from AWS STS at runtime

      - name: Deploy to ECS
        run: aws ecs update-service --cluster prod --service api --force-new-deployment

Practice Questions

Answer in your own words — then check against the expected answer.

Lesson Quiz