In a Kyverno policy, what does the context block do and how do you use its value?

## What the rule already knows, and what it does not When the API server calls Kyverno, it sends an AdmissionReview. That document carries the object being created or changed, the previous object on an update, the identity of the requester (user, groups, service account) and a `dryRun` flag. It carries **nothing else** - no other objects, no cluster state, no history. Any fact outside the request that your decision depends on has to be fetched, and in Kyverno that is what the `context` block is for. ## Shape of a context entry `context` sits inside a rule and is a list. Every entry has a `name` plus exactly one source: - **`configMap`** - `name` and `namespace` of a ConfigMap. The entry resolves to the object, so you read a key as `{{ <entryName>.data.<key> }}`. - **`apiCall`** - a `urlPath` against the cluster's own API (for example the Namespace of the request, whose labels the AdmissionReview does not include), usually narrowed with a `jmesPath` so you bind a small value rather than a whole list. - **`imageRegistry`** - a `reference` to a container image; Kyverno pulls the image's manifest and config metadata so a rule can assert on, say, a label baked into the image. - **`variable`** - a value or JMESPath expression, useful for naming an intermediate result so the rest of the rule reads cleanly. ## Referencing the value Anything Kyverno resolved is available as a `{{ }}` variable in the same rule: in `preconditions`, in `validate.deny` conditions or a `validate.pattern`, and in the `message` shown to the person whose request was refused. Putting the value in the message matters more than it looks - "zone must be one of euw1-a,euw1-b" tells a developer what to do next, where "placement policy violation" starts a support ticket. ## Why the indirection The worked example in the code block enforces that a workload only targets zones on a platform-owned allow list. The list is in a ConfigMap rather than in the policy, so adding a zone is a one-line data change owned by the platform team, and the policy YAML - which is the thing under change review - stays stable. Every team's Pods are governed by a rule none of them has to read. ## Three things that bite immediately **RBAC.** Kyverno reads the ConfigMap or makes the API call as its own controller ServiceAccount, through the API server, at admission time. Its shipped roles are deliberately narrow; if you point a context entry at something it may not read, the entry fails at runtime even though the policy was accepted at creation. You grant the extra read with an additional ClusterRole that Kyverno's own roles aggregate. **Types.** A ConfigMap `data` value is a string, always. `zones: "euw1-a,euw1-b"` is one string, not a list of two, so membership tests need `split(placement.data.zones, ',')` first. Storing the value as a JSON array in the ConfigMap is the other route. **Failure is not loud.** The policy is validated for structure when you create it; nothing checks that the ConfigMap exists or that the API path is readable. If the lookup fails at admission, that rule does not produce a violation - it produces an error result in the policy report, which a dashboard counting violations will happily show as zero problems. ## Preconditions and cost A context lookup happens per request on a matching object, so the cheapest control is a precise `match`/`exclude` block: kinds, namespace selectors and labels are evaluated before the rule body, and a rule that does not match is never processed at all. `preconditions` then express the cheap check over request fields - in the example, skip Pods that set no zone at all - so the rule only reaches its decision for requests it can actually judge. Getting the narrowing right in `match` first is what keeps an admission path predictable.