Lesson 18 / 24

Secrets in CI/CD

Use CI secret stores, service accounts and short-lived credentials instead of long-lived keys.

A machine needs its own identity

CI should never use a person's credentials. Create a service account with access to only the vaults a pipeline needs and store its token in the CI system's secret store. Where your cloud supports it, prefer short-lived credentials (OpenID Connect) over stored long-lived keys.

A GitHub Actions step

The service account token lives in GitHub Secrets. The step loads one secret into the job and masks it in logs.

- name: Load secrets
  uses: 1password/load-secrets-action@v2
  with:
    export-env: true
  env:
    OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
    DATABASE_URL: op://CI/Postgres/url

Never print in CI

Do not echo secrets or run shell tracing (set -x) in jobs that handle them. Be careful with pull requests from forks: do not expose secrets to untrusted code.

Quick check: What should a CI pipeline authenticate with?

  • A developer's personal login
  • A scoped service account
  • The master password
  • No authentication
Answer

A scoped service account — A service account can be limited and revoked without affecting any person.