Cosign & Sigstore

Every image reference in every manifest you have ever written is a promise nobody is enforcing: ghcr.io/mission-control/flight-planner:1.4.0 is a mutable pointer, and by default your cluster will run whatever bytes currently sit behind it without asking who put them there. Sigstore closes that gap without asking you to own a signing key. cosign is the CLI you actually run; Fulcio hands out a certificate that lives for about ten minutes, tied to a real identity from an OIDC login rather than a password only you know; Rekor writes every signing event into a public log nobody can quietly edit afterward. This page is the depth behind the Kyverno page's verifyImages section: the architecture, the resources you write in CI and at admission, the commands, and the gotchas that turn a "Verified OK" into false confidence.

What it is and the problem it solves

☺ Like you're 10: A borrowed stamp instead of a stolen key, and a logbook nobody can quietly edit.

Sigstore is a Linux Foundation project developed under the OpenSSF umbrella — it is not a CNCF project and carries no exam tile of its own on this course's nine-certification shelf, but it sits directly underneath one: the verifyImages rule type that makes up a real slice of KCA's heaviest domain. It is three cooperating pieces. cosign is the client you run to sign and verify. Fulcio is a certificate authority that issues X.509 certificates valid for roughly ten minutes, each one bound to an OIDC identity rather than to a key you generated yourself. Rekor is an append-only, cryptographically verifiable transparency log recording every signing event, so a signature cannot be minted quietly — it leaves a permanent, publicly auditable trace.

The problem underneath all of it: a tag is a mutable pointer, not a fact. A compromised CI token, a typosquatted base image, or a dependency that goes bad mid-build can all put different bytes behind flight-planner:1.4.0, and nothing in Kubernetes will notice. Pinning to a digest (@sha256:...) fixes mutability — the bytes cannot change out from under a fixed reference — but says nothing about provenance: an unchanged image is not the same claim as a legitimate one. Supply-chain attacks live in exactly that gap.

What you get at the end is three separable claims, and it's worth being able to name them apart. Integrity — these exact bytes, addressed by digest. Identity — signed by this workload's OIDC identity, vouched for by this issuer. Transparency — the event sits in a log anyone can audit. Attach an attestation on top and you get a fourth: provenance — a machine-readable statement of how the artifact was built and what's inside it.

Where it fits in the Golden Astronaut roadmap

☺ Like you're 10: Sealing happens back at the depot; checking the seal happens at the launch pad door — and they're different jobs, done by different people, at different times.

Signing belongs to the delivery plane — a step in CI, right after an image is built and pushed, alongside Argo Workflows or a GitHub Actions pipeline. Verification belongs to the governance plane — it happens at admission, inside the cluster, on every pod, and it is Kyverno's job to do it. Do only the first half and you have signatures nobody checks — a compliance decoration. Do only the second and nothing ever deploys, because nothing was ever signed to begin with.

The policy that enforces this belongs in Git like everything else this course treats as a guardrail: a ClusterPolicy reconciled by Argo CD or Flux, the same discipline the CGOA track builds around, so nobody can quietly weaken the signature requirement by hand against a live cluster. And because Sigstore sits underneath a real KCA competency without being a certification in its own right, it is exactly the kind of tool this course covers in depth even though it never appears on an exam blueprint by name — see Policy-as-Code Philosophy for the wider argument about what belongs at the cluster door at all. If you're also working the CNPA/CNPE track, Platform Engineering's cosign page covers the same tool with that exam's Security & Policy domain in mind — the mechanics below are identical either way.

How it works — the keyless flow

☺ Like you're 10: Borrow the stamp, seal the crate, write it in the logbook, hand the stamp back — then, on launch day, check the name in the logbook, not just that a seal exists.

Six steps, worth narrating from memory, because every gotcha later in this page is one of these steps failing quietly.

Keyed vs keyless

cosign supports both, and knowing when each is right matters more than memorizing flags.

A key can also live outside a flat file: cosign understands awskms://, gcpkms://, azurekms://, hashivault:// and k8s://namespace/secret references, strictly better than a key on disk when keyed signing is genuinely the right call.

Where signatures actually live, and attestations

A cosign signature is not embedded in the image manifest — it is a separate OCI artifact pushed to the same repository, under a tag derived from the digest. For sha256:abc123..., the signature lands as sha256-abc123....sig, attestations as ....att. Two consequences follow immediately: a registry garbage-collection policy that targets "untagged manifests" will happily delete signatures while leaving images behind, and a plain docker pull / docker push between registries leaves signatures behind entirely — cosign copy is what brings them along.

A signature says "I vouch for these bytes." An attestation says something richer: a DSSE-wrapped in-toto Statement carrying a subject (name plus digest), a predicateType, and a predicate payload. The two predicates that matter in practice are an SBOM — CycloneDX or SPDX, usually generated by Trivy or Syft — and SLSA provenance, which records the builder identity, source commit, and build parameters. SLSA grades that provenance in build levels: L1 means provenance merely exists; L2 means a hosted build service signed it; L3 means the build ran on hardened, isolated infrastructure resistant to forgery by the build itself — signing your own provenance from a shared CI runner is roughly L2, and getting to L3 is an infrastructure decision, not a cosign flag.

The resources you actually write

☺ Like you're 10: One pipeline step that seals the crate, and one policy that checks the name on the seal before the crate reaches the pad.

Signing in CI

Keyless means the pipeline needs no secret to sign with. In GitHub Actions the load-bearing line is permissions: id-token: write, which lets the job mint an OIDC token cosign finds automatically. Always sign the digest, never the tag — signing :1.4.0 signs whatever that tag resolves to at that exact instant, which is the same ambiguity the whole exercise exists to remove.

name: build-and-sign
on: { push: { branches: [main] } }

permissions:
  contents: read
  packages: write
  id-token: write            # REQUIRED — mints the OIDC token Fulcio trusts

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: sigstore/cosign-installer@v3
      - uses: docker/login-action@v3
        with: { registry: ghcr.io, username: ${{ github.actor }}, password: ${{ secrets.GITHUB_TOKEN }} }

      - name: Build, push, capture the digest
        id: push
        run: |
          IMAGE=ghcr.io/mission-control/flight-planner
          docker build -t "$IMAGE:${GITHUB_SHA}" .
          docker push "$IMAGE:${GITHUB_SHA}"
          DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' "$IMAGE:${GITHUB_SHA}")
          echo "digest=$DIGEST" >> "$GITHUB_OUTPUT"

      - name: Sign the image (keyless)
        run: cosign sign --yes "${{ steps.push.outputs.digest }}"

      - name: Generate and attest an SBOM
        run: |
          trivy image --format cyclonedx --output sbom.json "${{ steps.push.outputs.digest }}"
          cosign attest --yes --predicate sbom.json --type cyclonedx "${{ steps.push.outputs.digest }}"

Enforcing it at admission — the Kyverno side

Signing without enforcement is a checkbox, not a control. This is the exact rule Kyverno's page introduces and cross-links back here — read this one for what each field actually buys you.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  webhookTimeoutSeconds: 30              # registry + Rekor round-trips are not instant
  rules:
    - name: verify-keyless-signature
      match:
        any:
          - resources: { kinds: [Pod] }
      verifyImages:
        - imageReferences: ["ghcr.io/mission-control/*"]   # ours only — public bases can't be pinned this way
          failureAction: Enforce
          required: true
          mutateDigest: true              # rewrite tag -> digest once verified, closing the re-tag race
          attestors:
            - count: 1
              entries:
                - keyless:
                    # BOTH lines below are load-bearing — omit either and the rule is theatre
                    subject: "https://github.com/mission-control/*/.github/workflows/build-and-sign.yml@refs/heads/main"
                    issuer: "https://token.actions.githubusercontent.com"
                    rekor: { url: https://rekor.sigstore.dev }
          attestations:
            - predicateType: cyclonedx
              attestors:
                - count: 1
                  entries: [{ keyless: { subject: "https://github.com/mission-control/*/.github/workflows/build-and-sign.yml@refs/heads/main", issuer: "https://token.actions.githubusercontent.com" } }]

Two things worth carrying forward from the Kyverno page: mutateDigest: true is why verifyImages runs in the mutating phase rather than the validating one, and the default webhookTimeoutSeconds is tighter than a slow registry can comfortably meet — raise it deliberately on any policy carrying this rule, and read Kyverno's full breakdown of the four controllers before assuming a timeout is a broken signature.

Day-to-day commands

☺ Like you're 10: Four verbs — seal it, check the seal, write a note about what's inside, and check the note. Everything else is plumbing.

# --- signing ---
cosign sign --yes ghcr.io/mission-control/flight-planner@sha256:abc123...
cosign sign --key cosign.key ghcr.io/mission-control/flight-planner@sha256:abc...   # keyed, offline verification
cosign sign-blob --yes --bundle release.tgz.bundle release.tgz                      # sign a plain file, not an image

# --- verifying — BOTH pins are mandatory in cosign v2 ---
cosign verify \
  --certificate-identity "https://github.com/mission-control/flight-planner/.github/workflows/build-and-sign.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/mission-control/flight-planner@sha256:abc123... | jq .

# regex variant — "any workflow in this org, on main"
cosign verify \
  --certificate-identity-regexp '^https://github\.com/mission-control/.+@refs/heads/main$' \
  --certificate-oidc-issuer-regexp '^https://token\.actions\.githubusercontent\.com$' \
  ghcr.io/mission-control/flight-planner@sha256:abc123...

# --- where does it actually live? ---
cosign triangulate ghcr.io/mission-control/flight-planner@sha256:abc123...   # prints the .sig tag
cosign tree ghcr.io/mission-control/flight-planner@sha256:abc123...          # sigs + attestations, in one view
cosign copy ghcr.io/mission-control/flight-planner:1.4.0 registry.internal/mc/flight-planner:1.4.0  # brings sigs along

# --- attestations ---
cosign attest --yes --predicate sbom.json --type cyclonedx IMAGE@sha256:...
cosign attest --yes --predicate prov.json --type slsaprovenance IMAGE@sha256:...
cosign verify-attestation --type cyclonedx \
  --certificate-identity-regexp '^https://github\.com/mission-control/' \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  IMAGE@sha256:... | jq -r '.payload' | base64 -d | jq '.predicate'

Gotchas and failure modes

☺ Like you're 10: Checking that a seal exists is not the same as checking whose name is on it.

An unpinned verify proves almost nothing

Fulcio issues a certificate to anyone who can authenticate with any supported OIDC provider — that is the design, a public good rather than a gate. A signature that merely "verifies" with no --certificate-identity only proves that somebody with an email address signed those bytes. An attacker who compromises the registry can push a malicious image, sign it with their own throwaway identity, and sail through an unpinned check. Be equally careful with regexes: an unanchored mission-control also matches mission-control-evil-corp — always anchor with ^ and $ and escape the dots.

Signatures are separate artifacts, and they get lost

Three practical bites follow from the tag scheme. Registry garbage collection or retention rules keyed on "untagged manifests" will delete signatures while leaving images behind, and admission starts rejecting things that worked yesterday. Promotion between registries with a plain pull-and-push silently drops signatures — use cosign copy. And rebuilding instead of promoting defeats the whole model: if staging and production build separately, the digest differs, the old signature doesn't apply, and nothing about what actually runs has been verified.

Reachability turns into a cluster-wide pod-creation failure

Keyless verification is a network operation — the verifier needs the registry, a cached Sigstore trust root, and Rekor for the inclusion proof. Put that inside an admission webhook and a slow Rekor becomes pods failing to schedule cluster-wide, with symptoms that look like a broken policy rather than a slow dependency. Mitigations: raise webhookTimeoutSeconds, scope imageReferences narrowly instead of trying to verify public base images you can't pin anyway, and for genuinely disconnected estates, sign with the transparency log off (--tlog-upload=false) or run a private Sigstore deployment via cosign initialize --mirror.

Identity churn breaks a policy that used to pass

The certificate subject bakes in the workflow file's path and the ref it ran on. Rename the workflow, move the repository, or switch a trigger from refs/heads/main to a tag push, and every pinned policy stops matching — a perfectly legitimate image fails verification, usually noticed first as pods refusing to schedule. Treat identity strings as an interface with a change process, not a fact you write once and forget. And remember: signed does not mean safe — a faithfully signed image full of critical CVEs verifies perfectly, which is why cosign and Trivy are complements, never substitutes for each other.

Alternatives and when to choose it

☺ Like you're 10: Other people also invented seals. Sigstore's is the one that doesn't need you to guard a stamp between uses.

Choose keyless cosign for anything built by CI — nearly everything a platform team ships — because it removes the key-custody problem outright and its verifiers already exist everywhere. Choose keyed cosign with a KMS for disconnected environments or a regulator who wants a hardware-rooted release key with a documented custody chain. Look at Notation when the organisation already runs a PKI it must reuse. Don't let the comparison stall you — one correctly pinned verifyImages rule in production beats a perfect design of nothing.

Exam relevance and going further

☺ Like you're 10: You can't open Sigstore's website during a closed-book exam — the shape of the flow has to already be in your head.

Sigstore isn't one of this course's nine project certifications, but it sits directly under the domain that carries the most weight on KCA: verifyImages is one of the four rule types inside Writing Policies, and the KCA is a closed-book, multiple-choice knowledge exam — there is no terminal, no docs lookup, and no partial credit for "I'd look that up." That makes three things worth having cold: the six-step keyless flow with Fulcio and Rekor named correctly, the fact that an unpinned cosign verify proves almost nothing, and the shape of a verifyImages block with attestors[].entries[].keyless{subject,issuer}. Drill the full domain table and logistics on the KCA blueprint — this page is the depth behind that one line item. If GitOps delivery of the enforcing policy itself is the gap, CGOA is the adjacent shelf.