In a ValidatingAdmissionPolicy, how do you feed an approved-value allowlist to CEL without hard-coding it?

## The problem with an inline list The naive rule embeds the approved values in the expression itself: `object.spec.template.spec.nodeSelector['node-class'] in ['general', 'memory-optimised']` It works, and it is the wrong shape for anything that changes. Every new node class becomes an edit to a security-owned policy object, reviewed by the security team, with the risk that an expression change also changes matching or cost behaviour. The data and the logic are welded together. ## paramKind and paramRef A `ValidatingAdmissionPolicy` may declare `spec.paramKind`, naming the apiVersion and kind of a *parameter resource*. The policy does not name an instance — it names a type. The `ValidatingAdmissionPolicyBinding` supplies the instance through `spec.paramRef`, either by `name` or by a label `selector`. Inside a validation, the resolved resource is available as `params`, and you address its fields exactly as they are laid out in the resource. Typically the parameter kind is a small CustomResourceDefinition you own — something like a `NodePlacementPolicy` with a `spec.allowedClasses` list — because a CRD gives you a schema, validation and clear RBAC. A ConfigMap works when you want no CRD, at the cost of everything being strings. A few mechanics worth knowing: - **Selector binding fans out.** If `paramRef` uses a label selector that matches several objects, the policy is evaluated once per matched parameter object, and all of them must pass. That is a way to compose several independently-owned allowlists, and also a way to surprise yourself. - **`parameterNotFoundAction`** decides the behaviour when the reference resolves to nothing: `Deny` treats the missing parameter as a failed validation, `Allow` skips the policy. This is the fail-closed/fail-open switch for your data, and it is a security decision, not a default to leave unread. - **Namespaced parameter kinds** let the same policy resolve a different parameter object per namespace, which is how you give each team its own allowlist under one shared rule. - **Binding reuse.** The policy is written once; the bindings decide who it applies to and with which data. Adding a second environment is a new binding plus a new parameter object, not a second policy. ## What this buys, and what it does not What it buys is a clean separation of the rule from the data it compares against, with the data living in the cluster as an object you can review, audit and roll back. It also lets a platform team hand the allowlist to whoever legitimately owns it while keeping the expression itself locked down. What it does not buy is the ability to reach *outside* the cluster. `params` is still a Kubernetes object that something had to write. If your allowed set is genuinely owned by a system outside the cluster, `params` only helps if you also run something that mirrors that system into the parameter resource — and then the decision is being made against a copy, with whatever staleness the mirror has. ## The RBAC consequence people miss Once the allowlist is a resource, write access to that resource is effectively write access to the policy's verdict. Someone who can append to `spec.allowedClasses` can approve a node class without touching anything the security team reviews. Grant that permission as deliberately as you grant permission to edit the `ValidatingAdmissionPolicy` itself, and audit changes to it the same way. ## A note on the example expression The expression below permits a workload that sets no `node-class` selector at all — the presence guards short-circuit to true. That is usually not what you want; requiring the key is a second, separate validation. Splitting "the field must be set" from "the value must be approved" also gives you two distinct denial messages, which is the difference between a developer fixing their manifest in a minute and filing a ticket.