Your Kubernetes cluster pulls a container image. The image is from your internal registry. It has been in production for three weeks. Last week, someone with push access to the registry replaced it with a modified version — same tag, different content. You have no way to know this happened.
This is not a hypothetical attack vector. Registry push access control failures, compromised service account tokens, and CI/CD pipeline compromises all create paths through which a legitimate registry can serve illegitimate images. Without signing and provenance verification, you cannot distinguish a clean image from a tampered one at deploy time.
What Image Signing Provides?
Container image signing uses cryptographic keys to create a verifiable record that a specific image was produced by a specific build process and has not been modified since signing.
The core guarantees:
Integrity: A signed image with a verified signature is identical to the image that was signed. If any bit of the image was modified after signing, the signature verification fails. Tampered images cannot pass verification.
Provenance: The signature is produced by a specific key. Control of that key determines who can produce valid signatures. When the signing key is controlled by your CI/CD pipeline, only images that passed through your pipeline have valid signatures.
Non-repudiation: The signature record documents that a specific key signed a specific image at a specific time. This creates an audit trail for image production.
These guarantees address a class of attacks that CVE scanning cannot: attacks that modify an otherwise-clean image in transit or at rest. An image with no CVEs that has been tampered with is not safe. Signing verification catches the tampering that scanning cannot.
Sigstore and Cosign: The Practical Implementation
The Sigstore project has significantly reduced the complexity of implementing container image signing. Its cosign tool provides the primary interface for signing and verifying container images.
The basic signing workflow with cosign:
# Sign an image after it is pushed to the registry
cosign sign –key cosign.key registry.example.com/myapp:sha256-abc123
# Verify the signature before using an image
cosign verify –key cosign.pub registry.example.com/myapp:sha256-abc123
Sigstore’s keyless signing goes further: it uses ephemeral keys tied to OIDC identity tokens (from GitHub Actions, Google Cloud, etc.) to sign images without requiring long-lived key management. The signature records the OIDC identity and a transparency log entry that provides an auditable record.
Keyless signing is the recommended approach for most CI/CD environments because it eliminates key management complexity while providing stronger provenance: the signature includes the exact OIDC identity (which GitHub repository, which workflow, which branch) that produced the image.
The Provenance Chain
Provenance describes the complete history of an artifact: where it came from, what produced it, what inputs went into it. For container images, provenance includes:
Source reference: Which repository commit was built into this image?
Build process: Which pipeline, in which environment, running which build script produced this image?
Base image reference: Which version of the base image was used?
Dependency snapshot: What package versions were resolved and installed during the build?
The SLSA (Supply-chain Levels for Software Artifacts) framework provides a structured way to think about provenance levels. At SLSA Level 2, provenance is generated and signed by the CI/CD platform. At Level 3, the build is hermetically isolated and provenance is unforgeable.
Secure software supply chain practices that include provenance generation alongside image signing create a complete audit trail: you know not just that the image was signed but what was built into it and by whom.
Admission Control Integration
Signing and provenance are most valuable when they are enforced at admission time. An image signing requirement that is recommended but not enforced does not protect against an attacker who simply skips signing.
Kubernetes admission controllers provide the enforcement mechanism:
Policy Admission Controller with Kyverno: Define a Kyverno policy that requires all images to have a valid cosign signature from a specified public key. Pods referencing unsigned images are rejected.
OPA/Gatekeeper: Similar enforcement capability through Rego policy. The admission controller verifies the cosign signature before permitting pod creation.
Notary v2 / Ratify: The CNCF’s image verification framework provides a webhook-based admission controller that evaluates image signatures, attestations, and provenance records against configurable policy.
The enforcement pattern:
- Image is built and pushed to the registry
- CI/CD pipeline signs the image and generates provenance
- Kubernetes admission controller is called when a pod is created
- The admission controller verifies the image signature against the trusted key
- Pods referencing unsigned or invalidly-signed images are rejected
This makes the signing requirement structural rather than advisory.
Frequently Asked Questions
What is container image signing and why does it matter?
Container image signing uses cryptographic keys to create a verifiable record that a specific image was produced by a known build process and has not been modified since it was signed. It matters because registry push access failures, compromised CI/CD service accounts, and man-in-the-middle attacks on image pulls can all result in a tampered image reaching your cluster without any visible indicator. Signing verification catches tampering that CVE scanning cannot — a clean image with zero CVEs that has been modified after signing will fail signature verification and be rejected before it can run.
What is container image provenance and how is it different from signing?
Provenance is the complete build history of a container image: which source commit was built, which pipeline produced the image, which base image version was used, and what package versions were resolved. Image signing proves the image has not been tampered with; provenance proves what went into building the image in the first place. Together they create a full audit trail — signing ensures integrity in transit and at rest, while provenance documents the inputs so you can verify that the expected code, dependencies, and base image were used to produce the artifact.
How does container image signing work with Kubernetes admission control?
Kubernetes admission controllers can be configured to verify image signatures before permitting pod creation. Using tools like Kyverno, OPA/Gatekeeper, or Notary v2/Ratify, you define a policy that requires a valid cosign signature from a specified trusted key. When a pod is created, the admission controller verifies the image signature; pods referencing unsigned images or images whose signatures do not match the trusted key are rejected. This makes the signing requirement structural rather than advisory — images that did not pass through the authorized signing pipeline simply cannot run in the cluster.
How does combining container image signing with hardening improve overall security?
Signing and hardening address complementary threat vectors. Hardening reduces the attack surface by removing unused packages, minimizing CVE exposure in the content of the image. Signing verifies the integrity of the image artifact, ensuring the hardened image that was approved is the same image that runs in production. A hardening attestation signed alongside the image creates a verifiable record that the image went through the security pipeline — so admission control can require not just that an image is signed, but that it has a valid hardening attestation before it is permitted to run.
Connecting Signing to Hardening
Container image security through hardening and image signing address different threat vectors and are most powerful when combined.
Hardening addresses the content of the image: removing unused packages, reducing CVE exposure, minimizing the attack surface of what runs in the container.
Signing addresses the integrity of the image: ensuring the image that runs in production matches the image that was built and approved.
The combined workflow:
- Application image is built
- Runtime profiling and automated hardening produce the hardened image
- The hardened image is signed with the pipeline’s key (or keyless with the pipeline’s OIDC identity)
- Provenance is generated, recording the build inputs and the hardening attestation
- The signed, attested image is promoted to the production registry
- Admission control verifies both the signature and the hardening attestation before pods are created
The hardening attestation is the key addition: a verifiable record that the image went through the security pipeline and has a known CVE reduction status. This attestation travels with the image as a Cosign attachment and can be policy-evaluated at admission time.
Together, these controls create an image that is both clean (hardened, minimal CVE count) and verified (signed, with attestable provenance). The security properties are both established at build time and verifiable at runtime.