⚡ ~/naveed Interview Prep
⚡ Portfolio Home ✍️ Engineering Blog Deep Dives 🎯 Interview Hub 1,000+ Scenarios ☸️ Kubernetes Mastery Hub 24 Modules 🎮 DevOps Arcade & Quizzes Subnet Blitz ⚡ 🗺️ DevOps Roadmaps PDFs & Guides 🤖 Morpheus Analysis AI Quant ↗ 🛠️ Developer Tools Utilities 🧪 Labs & Experiments 📄 Interactive CV & Certs 🔗 All Links & Socials ⚡ Join The Dispatch (Weekly SRE Newsletter) →
← Back to All CI/CD & GitOps Interview Questions Scenario 170 of 176 in CI/CD & GitOps
Staff Infrastructure Architect CI/CD Continuous Delivery & GitOps Production Scenario

Q: Following an executive order on cybersecurity, your platform team must guarantee that every container deployed into production was built exclusively from approved source repositories via verified CI/CD workflows, without external tamper risks. You need to implement an immutable SLSA Level 3 provenance attestation pipeline that signs artifacts without static long-lived private keys, publishes in-toto attestations to the OCI registry, and enforces runtime verification in Kubernetes via Kyverno.

Implement end-to-end SLSA (Supply-chain Levels for Software Artifacts) Level 3 provenance generation and cryptographic verification using GitHub Actions trusted builders, Sigstore Cosign, and Kyverno admission controls.

#CI/CD #Security #SLSA #Supply Chain #Cosign
🎙️ Candidate Opening & Architectural Context
"Implement end-to-end SLSA (Supply-chain Levels for Software Artifacts) Level 3 provenance generation and cryptographic verification using GitHub Actions trusted builders, Sigstore Cosign, and Kyverno admission controls."
Advertisement
⚡ Recommended Practice Lab

Want to master this scenario in a live sandbox? KodeKloud's Enterprise GitOps with ArgoCD & Kubernetes Rollouts covers this exact problem with hands-on terminal drills.

🛠️ Production Runbook & Step-by-Step Resolution

Step 1

Integrate SLSA Official GitHub Actions Generator

Adopt the official SLSA GitHub Actions generator workflow (`slsa-framework/slsa-github-generator`). This workflow executes in an isolated, trusted GitHub runner with hardened permissions, verifying that the source code, build inputs, and container image digest cannot be forged by runner tampering.

name: SLSA Build
on:
  push:
    tags: ['v*.*.*']

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.build.outputs.image }}
      digest: ${{ steps.build.outputs.digest }}
    steps:
      - uses: actions/checkout@v4
      - id: build
        run: |
          docker buildx build --push -t ghcr.io/myorg/app:v1.0.0 .
          DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/myorg/app:v1.0.0 | cut -d'@' -f2)
          echo "image=ghcr.io/myorg/app" >> $GITHUB_OUTPUT
          echo "digest=$DIGEST" >> $GITHUB_OUTPUT

  provenance:
    needs: [build]
    permissions:
      id-token: write
      packages: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0
    with:
      image: ${{ needs.build.outputs.image }}
      digest: ${{ needs.build.outputs.digest }}
      registry-username: ${{ github.actor }}
    secrets:
      registry-password: ${{ secrets.GITHUB_TOKEN }}
Pro Tip: Integrate SLSA Official GitHub Actions Generator
Step 2

Generate and Inspect Cryptographic In-Toto Attestation

Use `cosign` to verify the generated predicate in the OCI registry. Inspect the JSON attestation containing the builder identity, source commit SHA, workflow inputs, and build environment metadata.

# Verify SLSA attestation using Cosign keyless verification
cosign verify-attestation \
  --type slsaprovenance \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/slsa-framework/slsa-github-generator/' \
  ghcr.io/myorg/app@sha256:d8b74a58...

# Extract and view the in-toto predicate
cosign verify-attestation --type slsaprovenance ghcr.io/myorg/app@sha256:... | jq '.payload | @base64d | fromjson'
Pro Tip: Generate and Inspect Cryptographic In-Toto Attestation
Advertisement
Step 3

Deploy Kyverno ClusterPolicy for Admission Enforcement

Configure Kyverno on the production Kubernetes cluster to reject any Pod whose container image lacks a valid SLSA provenance attestation issued by the enterprise repository.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-slsa-provenance
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-slsa-attestation
      match:
        resources:
          kinds: [Pod]
      verifyImages:
        - imageReferences: ['ghcr.io/myorg/*']
          attestations:
            - type: https://slsa.dev/provenance/v0.2
              conditions:
                - all:
                    - key: "{{ builder.id }}"
                      operator: Equals
                      value: "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0"
              issuer: https://token.actions.githubusercontent.com
              subject: https://github.com/myorg/*
Pro Tip: Deploy Kyverno ClusterPolicy for Admission Enforcement
Step 4

Audit Pipeline Failures and Supply Chain Threat Models

Conduct penetration tests simulating compromised build dependencies. Validate that unauthorized builds or locally pushed developer tags fail Kyverno validation and trigger security alerts.

Pro Tip: Audit Pipeline Failures and Supply Chain Threat Models
💡 The Senior SRE Gold Nugget (Key Architectural Takeaway)
"SLSA Level 3 provides non-falsifiable build provenance generated on isolated build platforms. Verifying in-toto provenance via Cosign and enforcing it via Kyverno ensures that only binaries built from approved source commits in hardened pipelines can execute in production."
⚡ 60-Second Elevator Pitch Talking Points
  • W
  • e
  • i
  • m
  • p
  • l
  • e
  • m
  • e
  • n
  • t
  • e
  • d
  • a
  • z
  • e
  • r
  • o
  • -
  • t
  • r
  • u
  • s
  • t
  • s
  • o
  • f
  • t
  • w
  • a
  • r
  • e
  • s
  • u
  • p
  • p
  • l
  • y
  • c
  • h
  • a
  • i
  • n
  • c
  • o
  • n
  • f
  • o
  • r
  • m
  • i
  • n
  • g
  • t
  • o
  • S
  • L
  • S
  • A
  • L
  • e
  • v
  • e
  • l
  • 3
  • .
  • B
  • y
  • u
  • t
  • i
  • l
  • i
  • z
  • i
  • n
  • g
  • t
  • h
  • e
  • o
  • f
  • f
  • i
  • c
  • i
  • a
  • l
  • S
  • L
  • S
  • A
  • c
  • o
  • n
  • t
  • a
  • i
  • n
  • e
  • r
  • g
  • e
  • n
  • e
  • r
  • a
  • t
  • o
  • r
  • i
  • n
  • G
  • i
  • t
  • H
  • u
  • b
  • A
  • c
  • t
  • i
  • o
  • n
  • s
  • w
  • i
  • t
  • h
  • S
  • i
  • g
  • s
  • t
  • o
  • r
  • e
  • k
  • e
  • y
  • l
  • e
  • s
  • s
  • O
  • I
  • D
  • C
  • s
  • i
  • g
  • n
  • i
  • n
  • g
  • ,
  • w
  • e
  • g
  • e
  • n
  • e
  • r
  • a
  • t
  • e
  • c
  • r
  • y
  • p
  • t
  • o
  • g
  • r
  • a
  • p
  • h
  • i
  • c
  • a
  • l
  • l
  • y
  • v
  • e
  • r
  • i
  • f
  • i
  • e
  • d
  • i
  • n
  • -
  • t
  • o
  • t
  • o
  • p
  • r
  • o
  • v
  • e
  • n
  • a
  • n
  • c
  • e
  • .
  • K
  • y
  • v
  • e
  • r
  • n
  • o
  • a
  • d
  • m
  • i
  • s
  • s
  • i
  • o
  • n
  • c
  • o
  • n
  • t
  • r
  • o
  • l
  • l
  • e
  • r
  • s
  • v
  • e
  • r
  • i
  • f
  • y
  • t
  • h
  • i
  • s
  • a
  • t
  • t
  • e
  • s
  • t
  • a
  • t
  • i
  • o
  • n
  • a
  • t
  • r
  • u
  • n
  • t
  • i
  • m
  • e
  • ,
  • p
  • r
  • e
  • v
  • e
  • n
  • t
  • i
  • n
  • g
  • u
  • n
  • t
  • r
  • u
  • s
  • t
  • e
  • d
  • o
  • r
  • r
  • o
  • g
  • u
  • e
  • c
  • o
  • n
  • t
  • a
  • i
  • n
  • e
  • r
  • b
  • u
  • i
  • l
  • d
  • s
  • f
  • r
  • o
  • m
  • d
  • e
  • p
  • l
  • o
  • y
  • i
  • n
  • g
  • .
Advertisement
Want more CI/CD & GitOps scenarios?
Explore our complete collection of scenario-based CI/CD & GitOps interview runbooks.
Browse All CI/CD & GitOps Questions →