Why we can’t trust an image tag for security
A tag such aslatest is a human-friendly label — not a permanent identifier. Because tags are mutable, relying on them introduces three major risks:
- Simple mistakes: a developer may accidentally reference a similarly named public image instead of your internal image.
- Malicious fakes: an attacker can publish a malicious image using the same name and tag as a popular image to trick users.
- Moving tags: an operator, CI system, or malicious actor can push a different image and update the tag to point to it. Your Kubernetes manifest may remain unchanged while the image pulled later is completely different.
Digest vs. tag
Every container image has two identifiers:- Digest: the image’s permanent fingerprint (for example,
sha256:...). It’s a hash computed from the image content and is immutable—changing any byte changes the digest. - Tag: a friendly name such as
my-app:latest. It’s a mutable pointer in the registry that maps to a digest.
my-app@sha256:<digest>
How tag movement creates risk (step-by-step)
- Your trusted CI builds a good image and pushes
my-app:latest. The registry pointslatestto the good digestsha256:ABC.... - Later, an attacker or broken process pushes a different image with digest
sha256:XYZ...using the same tagmy-app:latest. - The registry updates the
latestpointer tosha256:XYZ.... Your Kubernetes manifest still referencesmy-app:latest; when the cluster schedules a new Pod it may pull the malicious image.

The solution: cryptographic signatures
Cryptographic signatures bind a signer to an image digest and provide two guarantees:- Authenticity: who created (or signed) the image. A valid signature proves the image was signed by an entity that controls a trusted private key (for example, your CI/CD pipeline).
- Integrity: whether the image has been altered. The signature is associated with the image’s immutable digest; if the image is modified, the digest changes and signature verification fails.

End-to-end signing and verification flow
A typical signing and verification flow:- The CI/CD pipeline (the signer) builds the image and uses a tool — for example, Sigstore Cosign — with a private key (or keyless attestation) to sign the image.
- The pipeline pushes the image and its signature (or attestation) to the container registry.
- A developer submits a Kubernetes manifest that references the image to the cluster.
- Kyverno, acting as the verifier via an admission webhook, intercepts the admission request and checks the configured image verification rules.
- Kyverno fetches the signature from the registry and verifies it using the configured trust material (public keys or trust roots). If verification succeeds and the signer is trusted, the admission is allowed; otherwise it is denied.

Kyverno’s role — verifier, not signer
Kyverno does not generate signatures. Its responsibility is to verify signatures and enforce policies at admission time. Kyverno integrates with tools like Sigstore Cosign and Notary by fetching signatures/attestations from the registry and validating them against configured trust material (public keys or trust roots).Kyverno verifies image signatures during admission using configured trust sources. Signing is typically done by your CI/CD pipeline or a dedicated signing process.

Quick example: signing and verification commands
Below are concise examples showing how to sign an image with Cosign and how Kyverno/your pipeline can verify it. Replace placeholders with your actual values (<registry>, <repo>, <TAG>, <PATH-TO-KEY>, etc.).
Sign an image using a local key:
- Push the image and capture its digest (example output shows the digest):
- Use the digest in manifests to lock deployments:
Warning about protecting signing keys
Private signing keys must be stored and rotated securely. If an attacker obtains a private key they can sign malicious images that will pass verification. Use hardware-backed keys, secure secret management, or Sigstore keyless workflows where appropriate.
Summary
- Image tags (for example,
latest) are movable pointers and cannot be trusted as a security boundary. - The immutable image digest (for example,
sha256:...) is the true identity of an image. - Cryptographic signing provides authenticity and integrity by binding a signer to an image digest.
- Kyverno acts as a verifier, integrating with tools like Sigstore Cosign and Notary to enforce image-signature policies at admission.

Next steps
We will now put this theory into practice and walk through the actual commands and Kyverno policy examples used to sign images in CI/CD and enforce verification at admission.Links and References
- Kyverno — Kyverno documentation and image verification features
- Sigstore Cosign — Image signing and verification tool
- Notary (The Update Framework) — Trusted signing framework
- Kubernetes Documentation — Kubernetes resources and admission controllers