Container image signing and verification (Cosign, Notary)

Container images are the packaged artifacts most pipelines deploy, yet a raw image tag proves nothing about where the image came from or whether it was altered. Image signing solves this by attaching cryptographic signatures that verifiers can check before deployment. This lesson covers Cosign and Notary, the two dominant signing tools, and shows how signature verification closes the gap between building a trusted image and actually running it in production.

Analogy🏏Cricket

🎬 Think of it like movies: a film reel arriving at the cinema in an unmarked can could be tonight's premiere or a swapped-in bootleg — the label on the can proves nothing about what is actually on the film. Container images are those reels: the artifact your pipeline ships, yet a raw image tag says nothing about where the image came from or whether a frame was altered. Image signing attaches a cryptographic seal the projectionist can verify before threading the reel, so only the genuine cut ever screens. Cosign and Notary are the two dominant sealing tools. This reveals a signature as proof of origin and integrity a bare tag can never give.

The core problem is that image tags are mutable and identities are unverified. Anyone with registry access can push an image under a familiar tag, and a compromised registry could serve a tampered image entirely. Without verification, your cluster happily runs whatever the registry hands it. Signing binds an image's exact content digest to a private key, so a consumer can confirm both that the image is unchanged and that it was published by a trusted signer.

Analogy🏏Cricket

✈️ Think of it like travel: a boarding pass with just a name is worthless at the gate — names are easy to claim and reprint, so the airport binds you to a photo ID and a scannable code that cannot be quietly rewritten. Image tags are the bare name: mutable, so anyone with registry access can push a different image under the same familiar tag, or a compromised registry can serve a tampered one entirely. Signing binds the image's exact content digest to a private key, the equivalent of the tamper-proof ID. A verifier can then confirm both that the image is unchanged and that a trusted signer published it. This reveals verification as checking identity, not trusting a reusable label.

Under the hood, Cosign, part of the Sigstore project, signs an image's immutable digest and stores the signature alongside it in the registry. It supports keyless signing, where a short-lived certificate is issued against a verified identity and the signing event is recorded in a public transparency log, removing the burden of guarding long-lived private keys. Notary, the older CNCF standard, provides similar content-trust guarantees using a delegation-based key hierarchy for teams that prefer managed keys.

Analogy🏏Cricket

📷 Think of it like photography: a trusted press photo carries embedded metadata and a certificate proving which camera and photographer produced it, logged so any edit is exposed. Cosign, part of Sigstore, works the same way — it signs an image's immutable digest and stores the signature beside it in the registry. Its keyless mode issues a short-lived certificate against a verified identity and records the signing event in a public transparency log, so no one has to guard a long-lived private key. Notary, the older CNCF standard, gives similar content trust using a delegation-based key hierarchy for teams that prefer managed keys. This reveals signing as provable provenance, whether keyless or key-managed.

bash

# Sign an image with Cosign (keyless), then verify before deploy
cosign sign registry.example.com/app@sha256:<digest>

cosign verify \
  --certificate-identity-regexp 'https://github.com/org/repo/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  registry.example.com/app@sha256:<digest>
#   -> deployment proceeds only if the signature and identity check out

Analogy🏏Cricket

🏏 An unsigned image is like a trophy delivered in a plain box with no seal — it might be the real cup, or a clever replica swapped in transit. A Cosign signature is the tamper-evident hologram and the engraver's certified mark. Before the presentation, officials verify both: the seal is intact and the mark is genuine. Only then does the trophy — your image — go on stage in production. Waving the box through on its label alone is how a counterfeit cup ends up lifted on the podium; checking the seal and the mark at the boundary is how only the genuine trophy is ever presented. This reveals verification, not delivery, as the moment trust is actually earned.

Best practice makes verification mandatory and automatic at the deployment boundary. Sign images as the final step of a trusted build, verify signatures with an admission controller so unsigned or untrusted images are rejected before they ever run, and prefer keyless signing to avoid storing long-lived keys. Pin deployments to the immutable digest rather than a floating tag, and combine signing with the SLSA provenance from Module 1 so both origin and integrity are proven together.

Analogy🏏Cricket

🎵 Think of it like music: a concert hall does not simply trust anyone carrying an instrument case onto the stage — security at the stage door checks every credential, every time, automatically, and turns away anyone without a valid pass before they reach the microphone. Make signature verification that stage door: sign images as the final step of a trusted build, then have an admission controller verify the signature and reject any unsigned or untrusted image before it ever runs. Prefer keyless signing to avoid long-lived keys, pin deployments to the immutable digest rather than a floating tag, and pair signing with SLSA provenance. This reveals enforcement at the boundary as where trust is actually applied.

In the real world, a cluster protected by a signature-verifying admission controller simply refuses to schedule any image that was not signed by the organisation's own pipeline. If an attacker pushes a malicious image to the registry, the cluster rejects it at admission because no valid signature exists, and the incident becomes a blocked deployment and an alert rather than a running backdoor. Verification turns registry compromise from catastrophe into inconvenience.

Analogy🏏Cricket

🎮 Think of it like gaming: a well-run multiplayer server refuses to load any mod not signed by the official studio, so a hacker who slips a cheat-loaded map onto the file host simply watches it get rejected at connect time — the lobby never launches it. A cluster guarded by a signature-verifying admission controller behaves identically: it will not schedule any image that was not signed by the organisation's own pipeline. If an attacker pushes a malicious image to the registry, admission rejects it because no valid signature exists, and the event becomes a blocked deployment and an alert, not a running backdoor. This reveals verification as turning registry compromise from catastrophe into inconvenience.

Image tags are mutable and prove nothing about origin or integrity.
Signing binds an image's content digest to a trusted signer's key.
Cosign offers keyless signing with a public transparency log; Notary uses managed key hierarchies.
Enforce verification with an admission controller so unsigned images are rejected before running.
Pin to digests and pair signing with SLSA provenance for origin plus integrity.