Kubernetes validating admission policy

A ValidatingAdmissionPolicy on its own enforces nothing. Enforcement starts when a ValidatingAdmissionPolicyBinding attaches that policy to a scope, names the parameter resource the policy reads and chooses what happens on a violation. Keeping these roles separate is the main design decision in this feature. The policy holds the logic, the binding holds placement and parameter references, and the parameter resource holds values that differ between environments. Teams that merge these into one object often copy policies per environment, which makes drift hard to see. Before writing manifests, map each rule to one policy, list the bindings that will apply it and mark which values belong in parameters.

The policy spec has four parts that matter here. matchConstraints names the API groups, versions and resources the policy inspects, such as Deployments. paramKind declares the kind of parameter resource the policy expects, if it uses one. variables define named CEL expressions that are evaluated for each request, which keeps the validations short and readable. validations are the CEL expressions themselves, each returning true for a compliant object, with a message or messageExpression that the API server returns when a check fails. A policy can also set failurePolicy, which controls how the API server treats an evaluation error. Confirm exact field names and defaults in the official API reference for your Kubernetes minor version before you write manifests.

Illustrative example: the platform team wants every Deployment in a production namespace to carry an owner label. The policy, named require-owner-label, matches apps/v1 Deployments and has one validation that checks the object for the label key stored in its parameter. That key sits in a ConfigMap named owner-label-settings in a platform namespace, with a data entry such as requiredLabel set to owner. The binding, named owner-label-production, references the policy by name, points paramRef at that ConfigMap and uses a namespace selector that matches namespaces labeled environment: production. Its validationActions start with Warn and Audit, so teams see violations in client output and audit events without blocked deployments. Changing the required label later means editing the ConfigMap, and the policy stays as it is.

Scope and ownership need deliberate attention. Both ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding are cluster-scoped objects, so one binding can affect namespaces across the whole cluster, and a flawed policy applies everywhere it is bound. Who can create, edit or delete these objects is therefore an RBAC decision, separate from who can deploy workloads. Limit write access to a small platform group, and decide whether parameter resources need their own permissions so application owners can read required values without changing them. Confirm with your identity team how these roles map to groups, and make sure changes to policies and bindings appear in your audit logs so any loosened rule can be traced.

Teams start with Warn and Audit because they reveal which objects would fail a new rule before any request is blocked. Warn sends a message back to the client that submitted an object, so a developer running kubectl apply sees the policy's message in the response while the request still succeeds. Audit records each violation in the API server audit log, which gives owners a durable record they can query later, including for workloads nobody is changing today. In a ValidatingAdmissionPolicyBinding, the validationActions list controls this behavior. A first binding usually lists Warn and Audit and leaves Deny out, so the policy observes the cluster without changing what it accepts. Confirm the action names and their behavior against the Kubernetes version you run, since you will depend on that field's exact semantics.

Warnings and audit events answer different questions, so read them separately. Warnings fire only when an object is created or updated, which makes them a signal about change traffic: which teams still ship non-compliant manifests and through which pipelines. Audit events describe requests that reached the API server, so they are the better source for objects that already exist and for controllers that recreate pods. Audit events are only as complete as your audit policy. Confirm which resources, verbs and stages your policy records and at what level, because a policy that omits the relevant resources will show a quiet signal that means nothing. The Kubernetes audit logging topic covers writing that policy. Also confirm that events carry the policy and binding names so you can attribute each violation to a specific rule.

Existing objects are not changed when a new policy is bound, so the rollout plan needs a remediation list before Deny is considered. Build it from audit events for the policy and, to catch objects the audit window missed, from a read-only evaluation of current workloads in each namespace. For each violation, record the namespace, owning team, resource kind and name, the rule it breaks, the planned fix and who verifies it. Deployments, StatefulSets, DaemonSets and Jobs own their pods, so fix the pod template in the parent resource. A pod patched by hand will be recreated from the unchanged template on its next rollout, and the violation will return.

Notify the people who can act on each signal: application owners for namespaces with violations, the platform team that owns the policy and its bindings, security approvers who grant any exceptions, and the on-call rota for workloads likely to restart during fixes. Decide readiness per namespace, not for the whole cluster. A namespace is ready when its audit signal has stayed clean for an observation period the owners agreed in writing, every remediation item is closed or has an approved exception, and a rollback path exists that removes Deny from that binding. Set the length of the observation period against your own change process, and confirm it with your internal change owner before the window opens. Scope bindings so each namespace can move to Deny independently.

A validating webhook still makes sense when the admission decision needs something a CEL expression cannot reach or cannot express cleanly. Before choosing, confirm two things. First, the minor version your clusters run and whether the ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding APIs are served and enabled there, using the releases documentation for that version. Second, what your existing webhook actually does. Many webhooks only compare fields in the incoming object against fixed values or simple rules, and those are the easiest to move. Others do considerably more, and that difference decides the answer. Write out the list of checks each webhook performs before reading further, because that list is the basis for every other decision in this section.

CEL runs inside the API server against the admission request, the object and the old object, plus parameter resources and a limited set of variables. It has no general network access, so a rule that asks an external inventory, a licensing service, a secrets manager or a ticketing system whether a change is approved cannot be expressed as a policy. The same applies to logic that depends on state the request does not carry, such as the count of objects in another namespace at a given moment, unless you can model that state as a parameter resource that someone keeps current. Long chains of conditional logic, lookups across many objects, or rules that change often can also become hard to read and test as CEL. In these cases, a webhook that your team owns, versions and tests is the more suitable tool, provided you accept the operational cost described below.

A webhook is a service in the admission path. You run it as its own deployment, with its own TLS certificates for the API server connection and a process for rotating them. Its failure policy decides what happens when it is unreachable: fail closed blocks matching requests, and fail open admits them without the check. Both choices have consequences you should document before deployment. Its timeout adds latency to every matching API call. Its availability has to match the clusters it guards, which usually means redundant replicas, disruption budgets, careful ordering during upgrades, and excluding its own namespace from the rules it enforces to avoid deadlocks. Each of these recurs for as long as the webhook exists, and your team carries them in addition to the rule itself. Ask any partner quoting webhook work to list these recurring items separately from the build.

If the webhook's checks fit CEL, the migration usually runs in stages. Translate each rule into a ValidatingAdmissionPolicy with a binding that starts with the Warn or Audit action, so requests that would fail are reported without being rejected. Compare what the policy would have blocked with what the webhook blocked over a period your change process can support, and resolve the differences in either direction. Once they match, move the binding to Deny for the same scope, then remove the webhook's registration before removing its deployment. Keep the webhook running until the policy has been the only enforcer in every environment, since the two can disagree during the transition. Record each rule's old and new owner so no check disappears silently.

Some teams keep both. A policy handles the fixed rules, which run inside the API server, version with the cluster and need no extra service, while a narrow webhook handles the few checks that need external data. That split can be sensible, but it adds a second place to look when a request is denied, so document which mechanism owns each rule. Whatever you choose, confirm the decision against your own cluster version and the webhook's current code, not against this summary. A reviewer who can name each rule, its enforcer, its failure behavior and its owner has enough information to make the call.