In a Kyverno pattern over spec.containers, how many containers must match the sub-pattern?

## Universal by default When a Kyverno pattern contains an array, the element you write is a template applied to every element of the corresponding array on the resource. Write one container sub-pattern and it must hold for container zero, container one and container seventeen. This is the right default for a guardrail: a rule that requires a memory limit means *every* container, or it means nothing, because the one container you did not cover is the one that will eat the node. Many authors arrive expecting the opposite — that a list pattern is a filter, matching if some element matches. That intuition comes from query languages, and it is exactly backwards here. ## The existence anchor flips the quantifier `^()` is the anchor that changes the quantifier from *all* to *at least one*, and it is written on the key whose value is the array: ```yaml pattern: spec: ^(containers): - name: "audit-sidecar" ``` That says the pod must have at least one container named `audit-sidecar`; the others are unconstrained. It only makes sense for existence claims. Applied to a limits rule it becomes actively dangerous, because one well-behaved container satisfies the rule on behalf of every badly-behaved one in the same pod — a policy that reports green while the thing it was written to prevent ships every day. The question to ask before reaching for `^()` is which sentence you mean: "every container must…" or "the pod must contain a container that…". Only the second is an existence claim. ## Optional lists and the absence trap A pod may have no `initContainers` key at all. If your pattern names `initContainers` unanchored, then by the ordinary rule that unanchored keys are required, every pod without init containers is rejected — for the absence of the key, not for anything about limits. Your rule now blocks a large fraction of legitimate workloads and the message will point at a path developers cannot make sense of. The fix is the equality anchor: ```yaml pattern: spec: containers: - resources: limits: memory: "?*" =(initContainers): - resources: limits: memory: "?*" ``` `=(initContainers)` means: if the key is absent, check nothing; if it is present, the element sub-pattern must hold for every init container. Presence stays optional; correctness does not. The same shape recurs one level deeper for volumes. A rule that every `emptyDir` volume declares a `sizeLimit` is written as an optional `volumes` list whose elements carry an optional `emptyDir` object — `=(volumes)` with `=(emptyDir)` inside it — because most volumes are not `emptyDir` and a pod may have no volumes at all. Get the anchoring wrong there and you either reject every pod with a ConfigMap volume, or you assert nothing. ## What the developer is told Because the check is per element, the rejection message names the index: `failed at path /spec/containers/2/resources/limits/memory/`. That index is genuinely useful — it distinguishes "you forgot limits on the app container" from "your injected sidecar has none", which are different conversations with different owners. If you use a conditional anchor to skip an element, the indices in the message still refer to positions in the resource, so they remain a reliable pointer. ## Summary Default is universal, `^()` makes it existential, `=()` makes the list itself optional, and each of the three says something different about the policy you are actually writing. Choosing among them is the whole content of a list-shaped pattern.