In a Kyverno verifyImages rule, what does imageReferences select and what happens to an image it does not match?

## What a verifyImages rule is Kyverno is an admission-time policy engine for Kubernetes. Alongside `validate` and `mutate`, a rule can carry a `verifyImages` block, which is the rule type that reaches out to the container registry, checks signatures and attestations attached to an image, and decides whether the workload referencing that image may be admitted. Every `verifyImages` entry starts with the same question: *which images am I talking about?* That is what `imageReferences` answers. ## imageReferences is a pattern list, not an image `imageReferences` is a list of wildcard patterns compared against the image reference string as the rule resolves it — registry host, repository path, and tag or digest. A rule fires for an image if the image matches **at least one** pattern in the list. Typical entries look like: ```yaml imageReferences: - "registry.example.com/apps/*" - "ghcr.io/myorg/*" ``` Two mechanical points follow. First, the pattern is matched against the *whole* reference, so the registry host is part of what you are matching; a pattern written as `myorg/*` will not cover `ghcr.io/myorg/app`. Second, patterns are independent — adding a second entry widens the rule, it does not narrow it. ## Every image position in the pod spec A pod can reference images in more than one place: the application containers under `containers`, the setup images under `initContainers`, and any debug images injected as `ephemeralContainers`. A `verifyImages` rule considers all of them. This matters because the weakest image in a pod is often not the app image: a logging sidecar pulled from a vendor registry, or an init container that runs a database migration, gets the same access to the pod's volumes, service-account token and network namespace as the main process. A policy that only reasons about "the app image" is reasoning about the wrong threat. ## The unmatched image is the failure mode The single most important behaviour to internalise is that **no match means no evaluation**. The rule is not a default-deny over all images; it is a conditional check that only runs on images its patterns select. An image outside every pattern produces no pass and no fail from that rule, and unless some other rule covers it, the pod is admitted. This is what makes a typo or an over-narrow pattern dangerous. If a rule blocks unsigned images from `registry.example.com/apps/*` and a team starts deploying from `registry.example.com/platform/*`, nothing breaks, nothing is logged as a violation, and the guardrail quietly stops applying to a growing share of the estate. Compare that with the opposite mistake — a pattern that is too broad — which fails loudly the first time somebody deploys an image nobody signs, and gets fixed the same afternoon. A silent hole is worse than a noisy one because nothing forces you to look at it. ## Designing coverage Because every matching rule in every policy is evaluated, requirements accumulate rather than compete: if two rules both select an image, the image has to satisfy both. That composition is what makes a coverage strategy possible. A common shape is: - a broad rule whose `imageReferences` is effectively a catch-all, expressing the minimum every image must meet; - narrower rules per registry or per vendor, layering on stricter requirements — a specific signing identity, a required attestation — for images from that source. The coverage question then becomes answerable: rather than auditing each rule's pattern individually, you ask whether any running image fails to match the catch-all. Teams that skip the catch-all end up maintaining a pattern list that has to be updated every time a new registry appears, and they find out it was not updated only when someone goes looking. ## What to say in an interview Define `imageReferences` as a glob list scoping the rule; note that it spans containers, initContainers and ephemeral containers; then volunteer the negative case — an unmatched image is admitted unverified — and the mitigation of a catch-all pattern plus narrower layered rules. Volunteering the silent-pass behaviour is what separates someone who has run this in a cluster from someone who has read the field reference.