Image Signing With Cosign

Sign images at build; verify at deploy.

Sign

Container image signing is the supply-chain control that lets a Kubernetes cluster verify that the images it runs came from the trusted build pipeline rather than from somewhere else. Signing combined with admission-time verification produces a runtime gate against unauthorized images. cosign (part of the Sigstore project) is the dominant tool that has standardized this practice in 2026.

What signing actually involves:

• cosign sign command.: The build pipeline runs cosign sign against the just-built image. The command produces a cryptographic signature of the image's content-addressable digest. The signature proves that whoever held the signing key signed this exact image.
• Stored alongside image in registry.: The signature gets stored in the OCI registry as an attached artifact. The registry holds both the image and its signatures; pulling the image and verifying its signature both happen via the registry. No separate signature store; the existing infrastructure carries the signatures.
• Sigstore keyless mode.: Modern cosign supports keyless signing using OIDC identities. The CI authenticates with its identity provider; Sigstore mints a short-lived certificate; the signature is recorded in a public transparency log. No long-lived signing keys to manage.
• Multiple signatures per image.: An image can have multiple signatures from multiple parties: the build pipeline, the security scanner, the QA team. Each signature attests to a different property; verifiers can require any combination.
• Provenance metadata.: The signature can include provenance attestations: which CI built the image, which commit, which inputs. The attestation chain extends from "the engineer pushed code" through "the image was signed by the trusted CI" to "the image is running in production."

Signing is the cheap and easy part. The discipline is integrating it into every build pipeline so that every production image is signed.

Verify

Signing without verification is theater. The verification at deploy time is what enforces the trust. Kubernetes admission controllers verify signatures before allowing pods to run; unsigned or improperly-signed images are rejected.

• Admission controller verifies signature.: Kyverno, OPA Gatekeeper, sigstore policy controller all support image signature verification at admission. When a pod tries to start with an image, the admission controller pulls the signature, verifies it against the configured trust roots, and either allows or rejects the pod creation.
• Reject unsigned at deploy.: Pods using unsigned images cannot start. The admission controller blocks the creation; the deploy fails with a clear error. The cluster's invariant is "every running pod has a verified signature on its image"; unsigned images cannot get past this gate.
• Per-namespace policies.: Different namespaces may have different signing requirements. Production namespaces require signatures from the production build pipeline. Dev namespaces may accept signatures from any developer's build. The policy matches the namespace's trust level.
• Audit log of verification events.: Every verification (success and failure) is logged. The log shows which images passed, which were rejected, why. The log is the audit trail that proves the policy is being enforced rather than just configured.
• Continuous verification.: Some platforms support continuous verification: the cluster periodically re-verifies running pods' images. If a signature was revoked or the trust policy changed, the affected pods are flagged. The cluster's posture stays current.

Verification is the operational gate. Without it, signing produces an artifact that nobody checks; with it, signing produces a real security control.

Trust chain

The third leg of image signing is the trust chain: how the cluster decides whether a signature is valid. The chain extends from the CI that signed the image through the certificates and keys that anchor the signature to the cluster's verification.

• Public key in the cluster.: The verification configuration in the cluster includes the public keys (or, for keyless signing, the trusted issuers and identities) that the cluster trusts. Signatures from these keys are accepted; signatures from others are rejected. The trust is bounded.
• Build CI signs with private key.: The CI pipeline holds the signing key (or, for keyless, has the OIDC identity that maps to a trusted issuer). The CI signs every image it builds. The cluster's public key matches the CI's private key; signatures verify.
• End-to-end trust.: The chain extends from the engineer's commit through the CI's signature through the cluster's verification. Each link is mechanical; the chain proves "this image came from this commit through this trusted CI." The chain is what the supply-chain integrity story rests on.
• Key rotation.: Signing keys rotate. The cluster's verification configuration updates to include the new key while still trusting recent signatures from the old key. The rotation is staged; the period of dual trust prevents disruption during the transition.
• Compromised key revocation.: If a signing key is compromised, it gets revoked. The cluster's verification configuration removes the key from the trust list. Images signed with the compromised key are rejected; new images need to be re-signed with a current trusted key. The revocation is the recovery mechanism.

Image signing with cosign and admission-time verification is the supply-chain integrity pattern that modern Kubernetes deployments need. Nova AI Ops integrates with sigstore-based signing infrastructure, audits the signature coverage across the image inventory, and surfaces the cases where production images have signatures that need attention or trust roots that need rotation.