Skip to main content
Sometimes the safest reconcile loop is the one that never has to see a bad object. Validating admission policies let the API server reject unsafe requests before they are persisted, so your operator never has to reconcile invalid input.
The image illustrates the process of rejecting a bad web app request at admission using a validating admission policy before it is stored, ensuring the reconcile loop never sees it.
Think of admission as the Kubernetes API server’s front desk: every create or update request arrives there, gets checked, and only accepted objects proceed to storage and the reconciler. Validating admission policies express those checks using the Common Expression Language (CEL), a compact, safe expression language evaluated by the API server.
CEL expressions are evaluated inside the API server: they are not compiled Go code and they do not call your operator. You can use CEL to write concise, declarative checks against the incoming object.
The image displays text explaining that the rule sheet uses the Common Expression Language (CEL) and indicates that it is not code, specifically not a Go function or operator call.
Key objects in a validating admission setup
  • Policy: defines match criteria and the CEL expressions (rules) that must evaluate true.
  • Binding: enables a policy and chooses the enforcement action (deny, warn, audit).
Keeping Policy and Binding separate allows you to author reusable policies and enable them selectively via bindings.
The image illustrates a process where a "Binding" component with "Policy on" and "Enforcement: Deny" settings connects to a "Policy" component with rules and expressions.
Matching CRDs and referencing object fields
  • For a custom resource like a webapp, match typically targets API group webapp.cloudnative.space, version v1, and kind WebApp (or webapp depending on your CRD).
  • Inside a CEL expression, use the built-in object variable to read the incoming object (for example object.spec.image or object.spec.replicas).
  • Use has(...) to test for optional fields before evaluating them.
Practical rule examples and recommended CEL expressions Examples above show typical, object-local validations that CEL is designed for. Two short CEL examples:
Enforcement modes
  • deny: blocks requests that fail the CEL check.
  • warn: allows the request but surfaces a warning to clients.
  • audit: records violations (useful for monitoring and rollout).
Start with warn or audit when introducing a new policy to observe cluster impact before switching to deny.
The image shows two boxes titled "Warn" and "Audit" with brief descriptions under a section called "Softer Modes: Warn and Audit." There is also a note about observing violations before fully enforcing.
When to use CEL — and when not to CEL is a strong fit for concise, object-local rules that can be expressed as pure predicates. It is not a general-purpose programming extension for the API server: do not attempt side effects, external network calls, or large workflows inside CEL.
Do not use CEL for checks that require external API calls, side effects, or complex business logic. For those cases, implement a custom validating webhook or another admission design that can perform network calls and richer processing.
The image outlines the boundaries of CEL, indicating it's a "Good fit" for clear expressions and object-local checks, but "Not a programming extension" for tasks involving side effects, external calls, or large workflows.
Quick demo: apply a CEL-based validating admission policy for the webapp CRD
The objective is to have Kubernetes reject unsafe webapp requests before they are stored in the API server. References and further reading

Watch Video