Secrets in CI/CD: The Right Way to Store and Rotate Keys

Quickstart

If you only do a few things, do these first. They’re the highest-leverage changes for secrets in CI/CD, and they scale from a solo repo to a large org.

Overview

CI/CD is a privileged automation layer: it pulls source, builds artifacts, and often has the power to deploy to production. That makes CI secrets (API keys, signing keys, cloud credentials, webhook secrets) a high-value target. If an attacker gets one credential with broad permissions, they can pivot into your infrastructure.

Core concepts

Good secrets hygiene isn’t “never leak.” It’s designing your automation so that when something goes wrong, the impact is limited, detectable, and recoverable.

Secret vs credential vs key

Blast radius, least privilege, and time-to-live

When you can’t eliminate risk, you shape it: blast radius is “what can this credential do,” and TTL is “for how long.” The best CI setups shrink both.

Rotation vs revocation vs rollover

Step-by-step

This is a practical workflow you can implement incrementally. You don’t need to adopt every tool on day one. The key is to build a clear path from “secret exists” → “pipeline uses it” → “we can rotate it safely.”

Step 1 — Inventory secrets and classify them

Start with a simple spreadsheet or document. List every secret used by CI, where it is stored, what it is used for, and who owns it. Classification is how you decide what to fix first.

Step 2 — Choose a storage pattern (and be consistent)

Most teams use a combination: the CI platform secret store for small and simple secrets, and a dedicated secrets manager for shared, rotated, or high-sensitivity secrets.

Step 3 — Prefer short-lived credentials (OIDC/workload identity)

This is the single biggest “secrets in CI/CD” upgrade: instead of storing a static cloud key, your job requests a signed identity token from the CI provider and exchanges it for temporary access. No long-lived key to leak, and every run can be audited.

Example: a workflow that uses OIDC to obtain short-lived cloud credentials (no stored cloud keys). The exact action/provider names vary by platform, but the pattern is the same: trust the repo + branch, assume a role, do the deploy.

name: deploy

on:
  push:
    branches: [ "main" ]

permissions:
  id-token: write   # required for OIDC token minting
  contents: read

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

      # Exchange the CI OIDC token for short-lived cloud credentials.
      - name: Configure cloud credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/ci-deploy-role
          aws-region: eu-central-1

      - name: Deploy
        run: |
          set -euo pipefail
          ./scripts/deploy.sh

Step 4 — Lock down the trust relationship (don’t “trust all repos”)

OIDC is only as safe as the trust policy behind it. Tighten trust conditions so only the right repository, branch, and environment can assume the deployment role.

Example: an AWS IAM role trust policy for CI OIDC federation that restricts who can assume it. This is a Terraform snippet you can adapt (the values are placeholders).

resource "aws_iam_openid_connect_provider" "github" {
  url = "https://token.actions.githubusercontent.com"

  client_id_list = ["sts.amazonaws.com"]

  thumbprint_list = [
    # Use the correct thumbprint for your environment/provider.
    "6938fd4d98bab03faadb97b34396831e3780aea1"
  ]
}

data "aws_iam_policy_document" "assume_role" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRoleWithWebIdentity"]

    principals {
      type        = "Federated"
      identifiers = [aws_iam_openid_connect_provider.github.arn]
    }

    # Restrict by repository and branch:
    condition {
      test     = "StringEquals"
      variable = "token.actions.githubusercontent.com:sub"
      values   = [
        "repo:your-org/your-repo:ref:refs/heads/main"
      ]
    }

    # Restrict audience:
    condition {
      test     = "StringEquals"
      variable = "token.actions.githubusercontent.com:aud"
      values   = ["sts.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "ci_deploy_role" {
  name               = "ci-deploy-role"
  assume_role_policy = data.aws_iam_policy_document.assume_role.json
}

# Attach only the permissions required for deployment (least privilege).
resource "aws_iam_role_policy" "deploy_policy" {
  name = "deploy-policy"
  role = aws_iam_role.ci_deploy_role.id

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Action = [
          "s3:PutObject",
          "s3:ListBucket"
        ],
        Resource = [
          "arn:aws:s3:::your-artifact-bucket",
          "arn:aws:s3:::your-artifact-bucket/*"
        ]
      }
    ]
  })
}

Step 5 — Inject secrets safely into the job (and clean up)

Even if your secret is stored correctly, you can still leak it during execution. The safest pattern is: fetch/inject secrets at runtime, keep them in-memory when possible, and write to disk only when necessary (with strict permissions and cleanup).

Step 6 — Rotate keys using “overlap” (the safe rollout)

The most reliable rotation pattern is a staged rollover: you introduce a new credential while the old one is still valid, switch usage to the new one, verify, then revoke the old credential. This prevents sudden outages.

Example: a bash snippet that safely uses a secret (as a file) and supports an overlap window (ACTIVE/NEXT). The “get_secret_*” commands are placeholders for your CI or secrets manager integration.

#!/usr/bin/env bash
set -euo pipefail

# Avoid printing commands that might include secrets.
set +x

umask 077
tmpdir="$(mktemp -d)"
cleanup() { rm -rf "$tmpdir"; }
trap cleanup EXIT

# Fetch secrets from your secret store (placeholders).
ACTIVE_TOKEN="$(get_secret_value service/token/ACTIVE || true)"
NEXT_TOKEN="$(get_secret_value service/token/NEXT || true)"

# Prefer NEXT during rotation, fall back to ACTIVE.
TOKEN="${NEXT_TOKEN:-$ACTIVE_TOKEN}"

if [[ -z "${TOKEN}" ]]; then
  echo "ERROR: No token available (ACTIVE/NEXT missing)." >&2
  exit 1
fi

token_file="$tmpdir/token"
printf '%s' "$TOKEN" > "$token_file"

# Use the secret via file (safer than args; still avoid echoing).
curl --fail --silent --show-error \
  -H "Authorization: Bearer $(cat "$token_file")" \
  "https://api.example.internal/health" >/dev/null

echo "OK: token works (rotation overlap supported)."

Step 7 — Add audit and “break-glass” response

Make it easy to answer: “Who changed this secret?” and “Which pipelines used it?” Also define what happens when a secret leaks (because eventually something will).

Common mistakes

These are the patterns behind “we leaked a token” and “rotation broke production.” Fixing them usually takes less time than you think.

FAQ

Where should CI/CD secrets be stored?

Store secret values in a CI secret store (repo/org/environment secrets) or a dedicated secrets manager. Your pipeline config should only reference the secret by name/path. Never store secrets directly in YAML, code, or Git history.

Are environment variables safe for secrets in CI?

They can be safe enough if your CI platform masks them and you avoid printing them. The risk is accidental exposure via logs, subprocesses, or debug output. For extra safety, load secrets into a temp file with strict permissions and delete it after use.

How often should we rotate keys used in CI/CD?

Rotate based on risk and capability. For high-privilege credentials (deploy, signing), aim for regular rotation (monthly/quarterly) and a tested emergency revoke path. If you can switch to short-lived credentials (OIDC), you reduce the need for frequent value rotations because tokens expire automatically.

What’s the safest way to authenticate from CI to the cloud?

Use OIDC/workload identity to exchange a CI-issued identity token for short-lived cloud credentials. This avoids storing long-lived access keys in CI and sharply reduces the impact of accidental leaks.

How do we rotate a secret without breaking deployments?

Use a rollover: create a new credential, store it as NEXT, deploy code/config that prefers NEXT but can fall back to ACTIVE, verify production behavior, then revoke the old credential. Rotation should be boring and routine.

What should we do if a secret appears in logs?

Treat it as compromised. Revoke/rotate immediately, then investigate how it leaked and whether it was used. After containment, patch the leak source (debug output, tracing, scripts) so it can’t happen again.

Cheatsheet

A scan-fast checklist for secrets in CI/CD: storage, injection, and rotation.

Wrap-up

The “right way” to handle secrets in CI/CD is not one magic tool—it’s a workflow: keep secrets out of the repo, prefer short-lived credentials, restrict permissions, and make rotation routine. If you implement only one change, make it OIDC/workload identity for cloud access. It removes a whole class of long-lived keys that are easy to leak and painful to rotate.

Related posts

• Secrets Management: Stop Leaking Keys in Git and Logs
• CI/CD That Stays Green: Pipeline Patterns That Scale
• Kubernetes Security Basics: RBAC, Network Policies, and Images
• Test Your Infrastructure: Policy-as-Code and Guardrails
• Docker for Developers: Images, Layers, and Caching Explained
• Kubernetes Without Tears: Pods, Services, Ingress in One Story