Container Image Signing: Verifying What You Run

Why it exists

Unsigned software is vulnerable. An attacker could publish a malicious package with a similar name (typosquatting), compromise the server where an image is hosted, or tamper with an image after it has been published. Image signing was created to provide a verifiable link between an artifact and its author, ensuring authenticity and integrity.

The mental model

Think of container signing like a notary's seal on a legal document. The seal doesn't just say "this document is valid"; it says "this specific person, at this specific time, attested to the contents of this document." In the software world, it proves who created an artifact and that it hasn't been altered since they signed it. It shifts the trust from "I trust this registry" to "I trust this specific developer or build system."

How it works

Traditionally, signing required developers to manage long-lived private/public key pairs. The developer would sign the image digest with their private key, and consumers would need the corresponding public key to verify it. This created a key distribution and trust problem. Modern systems like Sigstore improve this by using short-lived, ephemeral keys generated for a single signing event. The identity of the signer is verified using an OpenID Connect (OIDC) provider, like GitHub or Google. The signature, public key, and identity certificate are then recorded in a public, tamper-resistant transparency log. Verification involves checking the signature against the log entry, confirming both the artifact's integrity and the signer's identity.

When to use it

Use image signing in any production environment or secure software supply chain. It's essential for regulated industries, open-source projects protecting their users, and any organization looking to prevent attacks where malicious code is injected into the build-to-deploy pipeline.

When not to use it

Signing is less critical for local development loops where the image never leaves your machine. The overhead, while minimized by modern tools, might not be justified for throwaway test images. However, any image intended for a shared environment like staging, QA, or production should be signed.

One canonical example

A CI/CD pipeline uses Sigstore's cosign tool. When a build completes, the pipeline authenticates to GitHub using OIDC. cosign sign is then called on the new image digest. Cosign generates an ephemeral key, gets a certificate binding the key to the CI job's identity, signs the image, and writes the signature to a transparency log. A Kubernetes cluster is configured with a policy controller that intercepts pod creation requests. Before running the image, the controller verifies its signature against the public log. If verification fails, the pod is rejected.