In a Kyverno variable, why does an unquoted nodeSelector key containing dots fail to resolve?

## The substitution language Everything between `{{` and `}}` in a Kyverno policy is a JMESPath expression evaluated against a document that includes `request` (the admission request), any context entries you declared by name, and a few Kyverno-provided values. JMESPath is a query language for JSON, and its most basic operator is the dot: `a.b.c` means "field `a`, then field `b` inside it, then field `c` inside that". That is fine until the key itself contains dots. Kubernetes label and selector keys almost always do: ``` nodeSelector: topology.kubernetes.io/zone: euw1-a ``` Here `nodeSelector` has exactly one key, whose *name* is the eleven-character-plus string `topology.kubernetes.io/zone`. Written unquoted, `nodeSelector.topology.kubernetes.io/zone` asks JMESPath for a field called `topology`, then `kubernetes` inside that, then `io/zone` inside that. There is no `topology` field, so the expression yields nothing. ## Quoting JMESPath spells a literal identifier with double quotes: `nodeSelector."topology.kubernetes.io/zone"`. Because the surrounding YAML scalar is usually itself double-quoted, the quotes get escaped, and the line looks noisier than the idea behind it. The same applies to annotation keys, to label keys like `app.kubernetes.io/name`, and to any ConfigMap key with a dot in it - a very common case, since teams like `zones.euw1` style keys. ## Unresolved is an error, not empty The reason this matters beyond neatness is what Kyverno does with a variable it cannot resolve: it treats it as an error for that rule rather than substituting an empty value. That is deliberate - silently comparing against nothing is how a guardrail becomes decorative - but it means an optional field needs an explicit default. JMESPath's `||` returns its right side when the left is unresolved or falsy, so `{{ request.object.metadata.labels.owner || '' }}` yields an empty string when the label is absent. A default alone is often not the right answer, though. If the empty string then fails your membership test, every Pod without the field is refused. The clean shape is: a **precondition** that checks the field is present and skips the rule when it is not, and a deny condition that judges only the requests the rule is actually about. That splits "this rule does not apply" from "this request is bad", which are two very different outcomes for the developer on the other end. ## Strings, not lists The second half of the same class of bug is typing. A ConfigMap's `data` values are strings. `zones: "euw1-a,euw1-b"` resolves to one string of thirteen characters, not a two-element list. Two ways out: - `split(placement.data.zones, ',')` turns it into a list, which pairs with the `AnyIn` / `AnyNotIn` operators. - Store the value as a JSON array in the ConfigMap and let it be parsed as a list. What you must **not** do is reach for `contains()` on the raw string. In JMESPath, `contains` on a string is a substring test, so `contains("euw1-a,euw1-b", "euw1-")` is true - and a rule built that way accepts values that were never on the list. It is the sort of bug that only surfaces when someone tries the near-miss value, which by then is production. ## How you find these A policy with an unresolvable variable is accepted at creation - the structure is valid, the expression's target is not knowable until a request arrives. So the failure is a runtime one, visible as an error result for that rule in the policy report and in the controller's logs, not as a rejected policy. Testing with the Kyverno CLI against a fixture resource is the fast loop: it will show you the rule producing an error instead of the pass or fail you expected, which is the signal that the path, not the logic, is wrong.