Skip to main content
Earlier we covered why image signing matters and how to sign images using the Notary CLI. In this lesson we automate signature verification using Kyverno’s image verification capabilities. Kyverno exposes a specialized rule block, verifyImages, for validating image signatures and attestations. Each verification statement includes a few important fields:
  • type — the signature system (for example, Notary or Cosign).
  • imageReferences — which images the rule should check (wildcards supported).
  • attestors — the trusted signers (public keys, certificates, etc.).
Minimum example verifyImages rule:
The imageReferences list tells Kyverno which images to protect. In the example above we target all tags of ghcr.io/my-org/my-app. The attestors block is the core of your trust policy — it declares which keys or certificates Kyverno accepts as valid signers.
The image shows a text box explaining that an attestor represents a trusted source, typically a public certificate for Notary. It is labeled "Configuring Attestors."
You can list multiple trusted entries and control how many must validate using count. If count is omitted, Kyverno requires all listed entries to pass (logical AND). Setting count: 1 requires at least one entry to pass (logical OR across entries).
Use count to support flexible trust models, for example accepting images signed by either a dev team key or a security team key.
If you omit count, Kyverno requires all listed attestors to validate (logical AND). This can be stricter than intended — explicitly set count to express OR semantics or multi-signer requirements.
Complete ClusterPolicy example The policy below matches Pods, resolves image tags to immutable digests during admission mutation, and enforces Notary signature verification using a PEM certificate:
The cert field holds the PEM-encoded public certificate that pairs with the private key used to sign the image. Kyverno uses this certificate to cryptographically verify signatures associated with the resolved image digest. How verification works (two stages)
  1. Mutation (tag → digest) When a Pod is submitted, the Kyverno admission webhook intercepts the request and scans container images. If an image tag matches imageReferences, Kyverno resolves that tag to the immutable digest stored in the registry. Kyverno mutates the Pod in-memory to replace the tag with that digest, effectively locking the exact image that will be pulled — preventing tag rebinding after verification.
The image depicts the verification workflow for mutation, broken down into five steps: "Admission Request," "Kyverno Intercepts," "Finds a Match," "Resolves the Tag," and "Mutates the Digest." The result is the image reference being "locked in" to a specific version.
  1. Validation (fetch signature → cryptographic check) After mutation, Kyverno connects to the registry to fetch the Notary signature associated with the resolved digest. Using the certificate(s) in the policy attestors, Kyverno verifies the signature. Kyverno then confirms the Pod’s image reference still uses the same digest. If all checks pass, admission is allowed.
The image illustrates a verification workflow, detailing connection and validation steps involving a registry and cryptographic checks using a policy's attestations.
If verification fails at any step — for example, the signature is missing, invalid, or signed by an untrusted key — Kyverno denies the admission request and the Pod is not created.
The image shows a diagram of a verification workflow process involving final validation and checks for an image reference. It indicates that if the signature is missing or invalid, the request is denied; otherwise, the request is allowed.
Performance and caching Fetching signatures and performing cryptographic verification on every Pod admission can be expensive. Kyverno uses an image verification cache to improve performance; this cache is enabled by default. How the cache helps:
  • The first time a specific image digest is successfully verified for a given policy, Kyverno stores a positive result in an in-memory TTL cache.
  • Subsequent Pods using the same image digest will hit the cache and be allowed immediately, avoiding a remote registry call and expensive crypto operations.
The cache trades freshness for performance. The default TTL (60m) may allow a revoked signature to be accepted until the cache entry expires. Choose cache settings based on your operational risk tolerance.
The image describes performance and caching strategies, highlighting image verification caching by default and the benefits of using cached results for policy evaluation. It includes cache configuration details such as enabling cache, max size, and TTL duration.
Admission Controller cache-related flags Summary
  • verifyImages is Kyverno’s mechanism for supply-chain image verification (Notary, Cosign, etc.).
  • Define type, protected imageReferences, and trusted attestors to express your trust policy.
  • Use attestors.count to control logical AND vs OR behavior across attestors.
  • Verification is two-phase: mutation (resolve tag → digest) and validation (fetch signature → cryptographic verification).
  • Kyverno uses an in-memory TTL cache to reduce verification overhead — tune cache settings to match your security posture.
The image shows a summary of key points about enforcing image trust using Kyverno, detailing specific rules, workflows, and performance considerations. It includes five main points, each highlighted with numbered icons.
You are now ready to author Kyverno policies that verify Notary image signatures. In later sections we will cover verifying attestations and Cosign-based verification. Links and references

Watch Video