Your Rego deny rule names only the first container missing resource limits — how do you fix it?

This is the complaint a platform team hears at five in the evening: a chart was rendered, the gate refused it, the message named one container, the developer fixed that container, re-rendered, and got refused again on a different one. Nothing is broken — the rule is doing exactly what it says — but the shape of the rule turns one review into four round trips. ## Why only one name comes out A comprehension is a single expression that produces a single value: ``` missing := [c.name | some c in input.spec.template.spec.containers; not c.resources.limits] ``` `missing` is an array. It is **always defined** — if nothing matches it is `[]`, never undefined, which is why `count(missing) > 0` is the right guard. But once the offenders are inside one array, any message built from `missing[0]` names one element by construction. The iteration that would produce several messages happened inside the comprehension and ended there; comprehension variables are scoped to the comprehension and do not leak into the body. ## The fix: bind in the body, let the set collect ``` deny contains msg if { some name in missing msg := sprintf("container %v has no resource limits", [name]) } ``` Now the body has an unbound variable again, so it is evaluated once per element, and the partial set rule collects one message per binding. No accumulator, no loop — the multiplicity comes from the bindings. (`contains` and `if` are the current keyword style; older policies wrote the same rule as `deny[msg] { ... }`.) If a complete rule had been used instead — `msg := ... if { some name in missing; ... }` — several distinct bindings would not silently pick one; evaluation fails with a conflict, because a complete rule may have only one value. That error is a useful signal that the rule shape is wrong for the job. ## The coverage half of the bug A pod spec has three container lists: `containers`, `initContainers` and `ephemeralContainers`. A rule that walks only the first will report a workload as clean while an init container runs unbounded. Rather than three near-identical rules, bind the field name and let iteration do the work: ``` missing contains c.name if { some field in ["containers", "initContainers", "ephemeralContainers"] some c in input.spec.template.spec[field] not c.resources.limits } ``` A variable can sit anywhere in a reference path, not just at an array index. If a spec has no `initContainers` key, that binding of `field` makes the reference undefined and simply contributes nothing — no error, no special case. Making `missing` a partial set rather than a comprehension also gives you deduplication for free, which matters when a chart renders several workloads with a shared sidecar name. ## The trap nobody spots in review The wrong way to cover two lists is to reuse one index variable: ``` some i c := input.spec.template.spec.containers[i] ic := input.spec.template.spec.initContainers[i] ``` Because `i` is unified across both references, only indices present in **both** arrays are considered. With three containers and one init container, exactly one pair is examined and everything else is silently skipped. The rule compiles, passes a superficial test with one container each, and under-reports in production. Use separate variables, or better, iterate values and never write an index at all. ## What this rule set is worth beyond the refusal The same `missing` set is the payload for two other things the platform team will be asked for. It is the body of an actionable denial — every offending container in one message rather than the first one. And it is the input to a mutating variant: the list of containers lacking limits, plus the defaults you would inject, is the same data whether you refuse the change or patch it on the way through. Computing the complete list is what makes either option available; a rule built around `missing[0]` can only ever refuse, one container at a time. ## Multi-document renders One last practical note: a rendered chart is a stream of documents, and how they reach the engine — one evaluation per document, or one array — changes the top of every path in the rule. Decide that before writing the paths, because a rule tested against a single manifest can quietly match nothing when handed a stream.