Image Signing with cosign and Sigstore

Why this matters

Module 00's second question was is it authentic and unmodified? — STRIDE's Tampering category, the exact gap track 11 module 01 previewed and said track 18 owns. A signature is the answer: after building, you cryptographically prove this exact image came from us and hasn't been altered, and later (module 05) admission control refuses to run anything that can't prove it. This is the control that stops the poisoned-base and tampered-image attacks from module 00 even when the image would scan clean, because a swapped image no longer carries a valid signature. This module makes signing real with cosign, and introduces the idea that changed the practice entirely — keyless signing, where you never manage a private key at all.

Concepts

What signing an image actually does

Signing binds a cryptographic signature to an image's digest — the immutable sha256: content identifier from module 00, not its tag. The signer computes a signature over the digest with a private key; anyone with the corresponding public key (or, for keyless, the transparency-log record) can verify that:

• the image content is exactly what was signed (integrity — any byte change breaks it), and
• it was signed by a specific identity you trust (authenticity).

Crucially, signing says nothing about whether the image is safe — a validly signed image can be riddled with CVEs. This is the "scanning vs signing" split track 11 drew, now from the signing side: scan answers "is it safe," signature answers "is it authentic." You need both, and module 05 enforces both at admission time.

cosign and the Sigstore project

cosign (from the Sigstore project, an OpenSSF effort) is the de-facto tool for signing container images and other OCI artifacts. It stores signatures in the registry, alongside the image — a signature is itself a small OCI object tagged by the image's digest — so your existing ACR/registry is also your signature store; there's no separate infrastructure. Sigstore has three pieces you'll meet:

• cosign — the CLI you run to sign and verify.
• Fulcio — a certificate authority that issues short-lived signing certificates tied to an identity (the heart of keyless, below).
• Rekor — a public, append-only transparency log that records every signature, so a signature can be verified later even though the certificate that made it has long expired.

This mirrors track 10/11's OIDC theme: just as secretless CI traded long-lived credentials for short-lived, identity-scoped tokens, keyless signing trades a long-lived signing key for a short-lived, identity-bound certificate.

Traditional key-based signing (and why the key is the problem)

The classic model: cosign generate-key-pair produces a private key (cosign.key) and public key (cosign.pub). You sign with the private key and distribute the public key to verifiers.

• Pro: conceptually simple, no external services required, works air-gapped.
• Con — and it's the big one: you now own a long-lived private key. It must be stored somewhere (a KMS, a secret in CI), rotated, access-controlled, and never leaked. A leaked signing key is catastrophic: an attacker can sign malicious images that pass every verification. This is the same long-lived- credential liability track 10 module 07 and track 11 module 02 warned about, now applied to signing keys.

cosign supports key-based signing backed by a KMS (including Azure Key Vault), which mitigates but doesn't eliminate the "there is a standing key to protect" problem. Keyless removes the standing key entirely.

Keyless signing via OIDC identity

Keyless signing eliminates the long-lived key. The flow, when your CI job signs:

1. cosign obtains an OIDC identity token — from GitHub Actions this is the same workflow OIDC token you used in track 10 for secretless Azure login; for a human it's an interactive "log in with Google/GitHub" flow.
2. cosign sends that token to Fulcio, which verifies the identity and issues a short-lived certificate (valid ~10 minutes) binding a freshly-generated ephemeral key to that identity (e.g. repo:myorg/myrepo:ref:refs/heads/main for a GitHub workflow).
3. cosign signs the image digest with the ephemeral key and records the signature + certificate in Rekor, the transparency log.
4. The ephemeral private key is discarded. There is no key to leak, store, or rotate.

Verification later checks: the signature is valid, the certificate was issued by Fulcio, the signing identity matches what you expect, and the entry is in Rekor. This is the model this track and the capstone standardize on, because it matches the OIDC-based, keyless CI you already built in track 10 — the CI job's identity is what signs, not a secret it holds.

Verifying: identity is the policy

For keyless, verification isn't "do I have the right public key?" — there's no standing key. Instead you assert which identity was allowed to sign, via two required checks:

• --certificate-identity (or --certificate-identity-regexp) — who signed, e.g. the exact GitHub workflow URL/ref, or you@example.com.
• --certificate-oidc-issuer — which issuer vouched for that identity, e.g. https://token.actions.githubusercontent.com for GitHub Actions or https://accounts.google.com for a Google login.

Both must be pinned. A signature that's cryptographically valid but was made by the wrong identity (or vouched for by the wrong issuer) must be rejected — otherwise anyone who can get any Fulcio certificate could sign your images. This identity-is-the-policy idea is exactly what module 05's admission controller encodes: "only images signed by this workflow identity may run." You'll deliberately trigger an identity-mismatch failure in the exercises, because getting this wrong is the most common keyless-verification bug.

Command reference

Flag breakdown for keyless verify: cosign verify --certificate-identity-regexp 'https://github.com/myorg/.+' --certificate-oidc-issuer https://token.actions.githubusercontent.com myreg.azurecr.io/app:1.0

• verify — check signatures on an image and print the verified payload; exits non-zero if no signature satisfies the checks (this is the gate module 05 automates).
• --certificate-identity-regexp 'https://github.com/myorg/.+' — who is allowed to have signed. Use the exact identity with --certificate-identity when you can; the regexp form is for "any workflow in my org." Getting this wrong (too loose, or not matching) is the #1 keyless failure.
• --certificate-oidc-issuer https://token.actions.githubusercontent.com — which OIDC issuer must have vouched for that identity. Pins the trust to GitHub Actions' issuer specifically; a signature from the same identity string but a different issuer is rejected.
• <image> — the image to verify; cosign resolves its digest and looks up the signature stored alongside it in the registry.

Flag breakdown for cosign sign --key azurekms://<vault>.vault.azure.net/<key> <img@digest>:

• --key azurekms://... — sign using a key held in Azure Key Vault instead of a local file, so the private key never leaves the KMS (the track 07/11 Key Vault pattern applied to signing). Still a standing key — better protected than a file, but not keyless.
• <img@digest> — always sign the digest, not a tag, so the signature binds to immutable content (module 00).

Hands-on exercises

cosign runs locally. You'll sign against a local registry so there's no Azure cost; the keyless-in-CI flow is demonstrated and explained (a real GitHub Actions run is the capstone).

1. (WSL2) Install cosign and start a local registry.

   curl -sSfL https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64 -o /tmp/cosign
   sudo install /tmp/cosign /usr/local/bin/cosign
   cosign version
   docker run -d -p 5000:5000 --name registry registry:2
   

   Expect a cosign version and a running local registry on localhost:5000.

2. (WSL2) Push an image and resolve its digest.

   docker pull alpine:3.20
   docker tag alpine:3.20 localhost:5000/alpine:3.20
   docker push localhost:5000/alpine:3.20
   DIGEST=$(crane digest localhost:5000/alpine:3.20 2>/dev/null || docker inspect --format '{{index .RepoDigests 0}}' localhost:5000/alpine:3.20)
   echo "$DIGEST"
   

   Expect a sha256:... digest. This is what you sign — never the tag.

3. (WSL2) Key-based signing: generate a key pair and sign.

   COSIGN_PASSWORD="" cosign generate-key-pair
   cosign sign --key cosign.key --yes localhost:5000/alpine@${DIGEST#*@} 2>/dev/null || \
   cosign sign --key cosign.key --yes localhost:5000/alpine:3.20
   

   Expect the signature to be pushed to the local registry next to the image. You now hold cosign.key — a long-lived private key you must protect. Feel the liability.

4. (WSL2) Verify the key-based signature — and watch it fail with the wrong key.

   cosign verify --key cosign.pub localhost:5000/alpine:3.20
   # Now generate a DIFFERENT key and verify with it:
   COSIGN_PASSWORD="" cosign generate-key-pair --output-key-prefix other
   cosign verify --key other.pub localhost:5000/alpine:3.20; echo "exit: $?"
   

   Expect the first verify to succeed and the second to fail (non-zero exit) — the signature was made by a different key. That pass/fail is the integrity/authenticity check module 05 will automate.

5. (WSL2) Inspect where the signature lives.

   cosign tree localhost:5000/alpine:3.20
   cosign triangulate localhost:5000/alpine:3.20
   

   Expect tree to show a Signatures entry and triangulate to print a ...sha256-<digest>.sig ref. Signatures are ordinary OCI objects in your registry — no separate signature server, exactly as Concepts said.

6. (WSL2) Break the signature by tampering, prove verify catches it. Push a different image to the same tag and re-verify against the old signature:

   docker pull alpine:3.19
   docker tag alpine:3.19 localhost:5000/alpine:3.20
   docker push localhost:5000/alpine:3.20
   cosign verify --key cosign.pub localhost:5000/alpine:3.20; echo "exit: $?"
   

   Expect verification to fail — the tag now points at content the signature doesn't cover. This is the tampered/poisoned-image attack from module 00 being caught by the signature, precisely the thing scanning could not do.

7. (WSL2) Read the keyless flow you'll run in CI. You won't run Fulcio/Rekor against a local registry, so study the exact commands the capstone's GitHub Actions job uses. In CI, with id-token: write permission (the track-10 OIDC setup), signing is just:

   # In GitHub Actions — no key, no secret:
   cosign sign --yes myreg.azurecr.io/app@${DIGEST}
   

   and verification anywhere is:

   cosign verify \
     --certificate-identity-regexp 'https://github.com/YOURORG/YOURREPO/.+' \
     --certificate-oidc-issuer https://token.actions.githubusercontent.com \
     myreg.azurecr.io/app:1.0
   

   Write down why there's no --key on either side: the CI job's OIDC identity is what signs (Fulcio issues a 10-minute cert), and verification trusts an identity, not a stored key.

8. Diagnose and fix: a keyless verification failing on identity mismatch. This is the #1 keyless bug. A teammate's verify fails even though the image is validly signed by the CI workflow:

   # Their (failing) command — wrong identity assumptions:
   cosign verify \
     --certificate-identity 'https://github.com/YOURORG/YOURREPO/.github/workflows/ci.yml@refs/heads/master' \
     --certificate-oidc-issuer https://accounts.google.com \
     myreg.azurecr.io/app:1.0
   

   Two things are wrong; diagnose both: (a) the branch is main, not master, so the exact --certificate-identity string doesn't match the signer; and (b) the issuer is Google, but the image was signed by a GitHub Actions workflow, so --certificate-oidc-issuer must be https://token.actions.githubusercontent.com. The correct command:

   cosign verify \
     --certificate-identity 'https://github.com/YOURORG/YOURREPO/.github/workflows/ci.yml@refs/heads/main' \
     --certificate-oidc-issuer https://token.actions.githubusercontent.com \
     myreg.azurecr.io/app:1.0
   

   The lesson: keyless verification failing is usually not a bad signature — it's an identity/issuer expectation that doesn't match who actually signed. When it fails, inspect the real signer with cosign verify output (or the Rekor entry) and align your --certificate-identity/--certificate-oidc-issuer to it, rather than assuming the signature is broken.

9. (WSL2) Clean up.

   docker rm -f registry 2>/dev/null; true
   rm -f cosign.key cosign.pub other.key other.pub
   docker rmi localhost:5000/alpine:3.20 alpine:3.19 alpine:3.20 2>/dev/null; true
   

Independent challenge

No commands given — build it using this module plus track 10's OIDC-based secretless CI and module 00's digest reasoning. In prose or as a real workflow snippet, design the signing step of a pipeline: state exactly where signing belongs in the build → SBOM → scan → sign → push order (and why it signs a digest, not a tag), choose keyless over key-based and justify it in terms of the long-lived-credential liability from track 10/11, and write the precise cosign verify command a consumer would run — with the exact --certificate-identity and --certificate-oidc-issuer values for your repo. Then explain, in two sentences, what an attacker who compromised your registry (but not your CI identity) could and could not do — and why the signature is what limits them.

Common mistakes & troubleshooting

• Signing a tag instead of a digest. Signatures bind to immutable content; sign app@sha256:.... Signing app:1.0 is ambiguous the moment the tag moves.
• Verifying keyless without pinning identity and issuer. A cryptographically valid signature from the wrong identity must be rejected. Both --certificate-identity/-regexp and --certificate-oidc-issuer are required — omitting either is a hole an attacker walks through.
• Assuming a verify failure means a bad signature. For keyless it's usually an identity/issuer mismatch (exercise 8): wrong branch in the ref, or the wrong issuer URL. Check who actually signed before assuming tampering.
• Treating a valid signature as "safe." Signing proves authenticity, not absence of CVEs. A signed image can be fully vulnerable — you still need the scan gate (track 11). Different axes.
• Keeping a long-lived signing key in a CI secret. That reintroduces exactly the leak-prone credential keyless was designed to remove (track 10/11). Prefer keyless; if you must use a key, put it in a KMS (Azure Key Vault), never a plaintext secret.
• Forgetting signatures are OCI objects your registry GC can delete. A registry cleanup that prunes "untagged" manifests can delete signatures. Use signature-aware retention so you don't orphan images from their proofs.

Checkpoint quiz

Write down your answer to each question before expanding it — checking without attempting first is the single easiest way to fool yourself into thinking you've learned this.

Cumulative review

Closed-book. Don't reopen modules 00–02 while attempting these — the point is to find out what actually stuck. These mix this track's first three modules with the baseline from track 11 (scanning, admission control) and track 10 (OIDC CI).

Next

Continue to 03-provenance-and-build-attestations — answer the third question, how was it built?, by generating SLSA provenance and attaching signed attestations (including your module-01 SBOM) to the image.