What Is Container Image Signing With Cosign?
Learn how Cosign signs container images with keyless signing, Fulcio, and Rekor, and how Kubernetes enforces signature verification.
Expected Interview Answer
Cosign is a tool from the Sigstore project that cryptographically signs container images and stores the signature alongside the image in the registry, so a deployment pipeline can verify the image was built and pushed by a trusted source and has not been tampered with before it runs in production.
Traditionally, signing meant managing long-lived private keys yourself, which is risky if a key leaks; Cosign supports that classic keypair flow but also pioneered keyless signing, where a short-lived certificate is issued by Sigstore’s Fulcio certificate authority after the signer proves their identity via an OpenID Connect provider (like a GitHub Actions workflow token), and the signature event is recorded immutably in the public Rekor transparency log instead of relying on a long-lived secret. At deploy time, a policy engine like Kyverno, OPA Gatekeeper, or Kubernetes’ built-in admission webhooks calls `cosign verify` (or an equivalent library) to check the image’s signature against the expected identity and reject any unsigned or tampered image before it is scheduled. This closes a major supply-chain gap: without signing, anyone with registry push access, or an attacker who compromises the registry, could substitute a malicious image with the same tag and it would run indistinguishably from the legitimate one.
- Prevents unsigned or tampered images from reaching production
- Removes long-lived private key management via keyless signing
- Creates a publicly auditable, immutable signing record via Rekor
- Integrates directly with Kubernetes admission control for enforcement
AI Mentor Explanation
Cosign is like a match ball being stamped with an official, tamper-evident seal by the umpire the moment it is approved for play, so any team can verify at the boundary rope that the ball in play is the exact one certified, not a scuffed-up substitute. The keyless flow is like the umpire proving their own identity to the match referee on the spot rather than carrying a pre-issued permanent pass that could be stolen. Every stamping event is logged in the official scorebook (the transparency log) for anyone to audit later. A team caught trying to swap in an unstamped ball is disqualified before the over even starts, just as an unsigned image is rejected before deployment.
Step-by-Step Explanation
Step 1
Build and push the image
CI builds the container image and pushes it to a registry with a content-addressable digest.
Step 2
Sign with Cosign
CI runs cosign sign, using a keyless flow (OIDC identity + Fulcio short-lived cert) or a stored keypair.
Step 3
Record in the transparency log
The signature event is written to Rekor, giving a public, immutable audit trail.
Step 4
Enforce at deploy time
An admission controller (Kyverno/OPA) runs cosign verify against the expected identity and blocks unsigned or mismatched images.
What Interviewer Expects
- Understanding of why image signing closes a registry-tampering gap
- Knowledge of keyless signing via OIDC identity and Fulcio short-lived certs
- Awareness of Rekor as a public transparency log for auditability
- Ability to explain how admission control enforces signature verification
Common Mistakes
- Believing image signing alone scans for vulnerabilities (it verifies provenance, not content safety)
- Assuming keyless signing means no verification of identity at all
- Forgetting that signatures must be verified at deploy time, not just created at build time
- Confusing image digests (content hash) with tags (mutable pointers) when discussing what gets signed
Best Answer (HR Friendly)
“Cosign lets us cryptographically sign every container image we build, so our deployment pipeline can prove the image running in production is exactly the one our CI system built and pushed, not something swapped in later. With keyless signing we do not have to manage long-lived secret keys ourselves — identity is proven through our CI provider, and every signature is recorded in a public, tamper-proof log, which gives us strong supply-chain security with less operational risk.”
Code Example
# Sign an image using keyless (OIDC) signing in CI
cosign sign --yes registry.example.com/myapp@sha256:abc123...
# Verify the signature came from a trusted GitHub Actions identity
cosign verify \
--certificate-identity-regexp “https://github.com/myorg/.*” \
--certificate-oidc-issuer “https://token.actions.githubusercontent.com” \
registry.example.com/myapp@sha256:abc123...
# Inspect the signature transparency log entry
cosign verify --output text registry.example.com/myapp@sha256:abc123...Follow-up Questions
- How does keyless signing avoid managing long-lived private keys?
- What role does the Rekor transparency log play in Sigstore?
- How would you enforce signature verification at the Kubernetes admission layer?
- Should you sign by tag or by digest, and why?
MCQ Practice
1. What problem does container image signing primarily solve?
Signing establishes provenance and integrity — that the running image is exactly what a trusted pipeline produced.
2. In Cosign's keyless signing flow, what issues the short-lived signing certificate?
Fulcio issues a short-lived certificate once the signer proves identity through an OIDC provider, avoiding long-lived private keys.
3. What is the purpose of the Rekor transparency log?
Rekor records signing events immutably and publicly so anyone can audit when and by whom an image was signed.
Flash Cards
What does Cosign do? — Cryptographically signs and verifies container images, part of the Sigstore project.
What is keyless signing? — Signing using a short-lived cert issued via OIDC identity instead of a long-lived private key.
What issues the short-lived cert? — Fulcio, Sigstore's certificate authority.
What is Rekor? — A public, immutable transparency log recording every signing event.