Stop 06 · CI/CD PipelinesTopics · 10/10

Secrets Management in Pipelines

In short

Pipelines need passwords, API keys and cloud access to deploy. Put them in the YAML and anyone with repo access, or a fork, can read them. Here's how to hand secrets over safely.

Injecting sensitive values (API keys, credentials) into a pipeline securely, without hardcoding them in version-controlled files where anyone with repo access could see them.

The mascot at an ATM shields the keypad with one hand while holding a plain bank card.

Think of it like this

Never write the PIN on your ATM card

Your ATM card and your PIN travel separately for a reason. If someone finds the card with '4821' written on the back, it's game over. Secrets in pipeline files are a PIN written on the card. Keep the card (code) and the PIN (secret) apart.

Watch it happen

Deploying to AWS without stored keys (OIDC)

CI job

CI OIDC

AWS STS

request ID token

1/5The job asks its CI platform for a signed token that says which repo and branch it is.

The big ideas

What you need to know

Use the platform's secret store

GitHub, GitLab and Jenkins all store encrypted secrets and inject them as env vars at runtime.

Masking isn't a guarantee

Logs hide exact secret values, but encoding or splitting one can leak it. Never echo secrets on purpose.

Short-lived beats long-lived

OIDC and vaults hand out credentials that expire in minutes or hours. A leaked one soon becomes useless.

Scope by environment

Give production secrets only to jobs on protected branches, ideally with an approval step.

See it in code

Walk through the code

yaml

1on: push2permissions:3  id-token: write     # allow the job to request an OIDC token4  contents: read5jobs:6  deploy:7    runs-on: ubuntu-latest8    environment: production9    steps:10      - uses: aws-actions/configure-aws-credentials@v411        with:12          role-to-assume: arn:aws:iam::123456789012:role/deploy13          aws-region: ap-south-114      - run: ./deploy.sh15        env:16          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}

1/4Let the job request an OIDC token, and keep repo access read-only.

The AWS role and its trust policy are set up once in IAM. The account ID here is a placeholder.

Save yourself the pain

Common mistakes

Oops

Committing a .env file or pasting a key into the pipeline YAML 'just for now'.

Do this instead

Treat any committed secret as leaked: rotate it immediately, then move it to the secret store.

Oops

Making production secrets available to pipelines from pull requests and forks.

Do this instead

Limit them to protected branches or environments with required reviewers.

Your mission

Use a secret safely

~20 min

Quick check

Why is OIDC better than storing a long-lived cloud access key as a CI secret?

Go deeper

1Set up a secret in your CI/CD platform's secret store and reference it in a pipeline step.
2Learn why committing a secret to Git (even briefly) is a serious security incident, not a minor mistake.
3Understand the basic difference between pipeline-level secrets and dedicated secret managers (Phase 12).