Skip to main content

04. OIDC Authentication & Cryptographic Artifact Signing

Securing the boundary between CI/CD pipelines and production infrastructure requires two core architectural controls: eliminating long-lived static cloud credentials and cryptographically signing all compiled software artifacts.

This chapter details OpenID Connect (OIDC) federation and container image signing using Sigstore/Cosign.

1. Eliminating Static Credentials with OIDC Federation​

Storing long-lived cloud API keys (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, GCP service account JSON keys) in GitHub Secrets creates a critical risk: if a pipeline runner is compromised, attackers extract keys that grant persistent access to enterprise cloud environments.

OpenID Connect (OIDC) allows CI/CD runners to request short-lived, dynamically minted OAuth 2.0 / JWT tokens directly from the cloud provider (AWS, GCP, Azure).

AWS OIDC Integration Setup​

Step 1: AWS IAM Role Trust Policy (github-oidc-policy.json)​

Configure an AWS IAM Role trust policy that restricts assumption to a specific GitHub organization, repository, and branch:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:techcorp/api-service:ref:refs/heads/main"
        }
      }
    }
  ]
}

Step 2: GitHub Actions Workflow (.github/workflows/deploy.yml)​

name: Deploy to Production AWS
on:
  push:
    branches: [ main ]

# CRITICAL: Grant permission to request OIDC JWT ID token
permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.7

      - name: Authenticate to AWS via OIDC
        uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsDeployRole
          aws-region: us-east-1
          # NO STATIC KEYS STORED IN SECRETS!

      - name: Deploy to Cloud
        run: |
          aws ecr get-login-password --region us-east-1 | docker login ...

2. Cryptographic Container Image Signing (Sigstore / Cosign)​

Mutable container tags (:latest, :v1.0.0) can be overwritten by unauthorized registries or man-in-the-middle attackers. Container image signing guarantees that Kubernetes clusters run ONLY container images built and signed by authorized CI/CD workflows.

Sigstore provides an open-source standard for artifact signing backed by Linux Foundation and OpenSSF.

┌─────────────────────────────────────────────────────────────────────────────┐
│                          SIGSTORE ECOSYSTEM ARCHITECTURE                    │
├──────────────┬──────────────────────────────────────────────────────────────┤
│ Cosign       │ CLI tool for signing and verifying OCI container images.     │
├──────────────┼──────────────────────────────────────────────────────────────┤
│ Fulcio       │ Ephemeral Certificate Authority issuing short-lived X.509    │
│              │ certificates tied to OIDC identity (e.g. GitHub Workflow).  │
├──────────────┼──────────────────────────────────────────────────────────────┤
│ Rekor        │ Immutable, append-only transparency log auditing all signed   │
│              │ certificates and image digests globally.                    │
└──────────────┴──────────────────────────────────────────────────────────────┘

Cosign Keyless Signing Workflow in GitHub Actions​

Keyless signing uses OIDC identity tokens to obtain temporary signing certificates from Fulcio, publishing public audit records to Rekor without managing private key files!

# .github/workflows/build_and_sign.yml
name: Build, Sign, and Push Container Image
on:
  push:
    branches: [ main ]

permissions:
  id-token: write # Required for Sigstore keyless OIDC authentication
  contents: read
  packages: write

jobs:
  build-and-sign:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.7

      - name: Install Cosign CLI
        uses: sigstore/cosign-installer@59acb6260d9c0d3bbf966565078588ef73c7165c # v3.5.0

      - name: Log in to GitHub Container Registry (GHCR)
        uses: docker/login-action@0d4c9c5ea7693da7b069a1841bce44c3a93d6d3d # v3.2.0
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and Push Docker Image
        id: build-image
        uses: docker/build-push-action@ca052bb54ab0790a636c9b5f226502c73d547a25 # v5.4.0
        with:
          push: true
          tags: ghcr.io/techcorp/api-service:${{ github.sha }}

      - name: Sign Container Image (Keyless Sigstore)
        env:
          IMAGE_DIGEST: ghcr.io/techcorp/api-service@${{ steps.build-image.outputs.digest }}
        run: |
          # Cosign authenticates via GitHub OIDC ID Token automatically
          cosign sign --yes "$IMAGE_DIGEST"

3. Kubernetes Admission Control Enforcement (Kyverno)​

Generating signatures in CI/CD provides security only if the production Kubernetes cluster enforces signature verification prior to pod deployment.

Deploy a Kyverno ClusterPolicy to intercept pod creation requests and reject unsigned images:

# kubernetes/kyverno-verify-images.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-container-signature
  annotations:
    policies.kyverno.io/title: Verify Signed Container Images
    policies.kyverno.io/subject: Pod
spec:
  validationFailureAction: Enforce # Block non-compliant deployments
  background: false
  rules:
    - name: verify-signature-sigstore
      match:
        any:
        - resources:
            kinds:
              - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/techcorp/*"
          attestors:
            - entries:
                - keyless:
                    issuer: "https://token.actions.githubusercontent.com"
                    subject: "https://github.com/techcorp/api-service/.github/workflows/build_and_sign.yml@refs/heads/main"
                    rekor:
                      url: "https://rekor.sigstore.dev"

4. Generating & Verifying SLSA Provenance​

In addition to signing container images, attach cryptographically verifiable SLSA Provenance attestations using the slsa-github-generator:

# Step inside build workflow calling SLSA Generator reusable workflow
jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digests: ${{ steps.hash.outputs.digests }}
    steps:
      - id: hash
        run: echo "digests=`$(sha256sum binary-artifact | base64 -w0)" >> "$`GITHUB_OUTPUT"

  provenance:
    needs: [build]
    permissions:
      id-token: write
      contents: read
      actions: read
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.0.0
    with:
      base64-subjects: "${{ needs.build.outputs.digests }}"

Next Chapter: 05. Pipeline Security Gates & Governance →

Share this guide
𝕏 Twitterin LinkedIn↗ Reddit✉ Email