> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # CEL Admission Policies > Using CEL validating admission policies in Kubernetes to declaratively reject invalid or unsafe custom resource requests before persistence 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. | Resource | Purpose | Example | | -------- | ------------------------------------------------------------------- | ------------------------------------------------- | | Policy | Defines which requests to match and the CEL expressions to evaluate | `validatingadmissionpolicy/webapp-rules` | | Binding | Turns a Policy on and selects the enforcement action | `validatingadmissionpolicybinding/webapp-binding` | 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 | Rule | Purpose | CEL expression | | -------------- | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Image pinning | Disallow moving tags like `:latest` so deployments are reproducible | `cel\n!object.spec.image.endsWith(':latest')\n` | | Replica limits | Allow omitted replicas, but if provided require 1..10 | `cel\n!has(object.spec.replicas) \|\| (object.spec.replicas >= 1 && object.spec.replicas <= 10)\n` | Examples above show typical, object-local validations that CEL is designed for. Two short CEL examples: ```cel theme={null} # Disallow :latest tags !object.spec.image.endsWith(':latest') ``` ```cel theme={null} # Allow missing replicas, otherwise require 1..10 !has(object.spec.replicas) || (object.spec.replicas >= 1 && object.spec.replicas <= 10) ``` 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 ```bash theme={null} $ kubectl apply -f webapp-policy.yaml validatingadmissionpolicy/webapp-rules created ``` The objective is to have Kubernetes reject unsafe webapp requests before they are stored in the API server. References and further reading * CEL spec: [https://github.com/google/cel-spec](https://github.com/google/cel-spec) * Kubernetes Admission Controllers overview: [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) * ValidatingAdmissionPolicy docs: [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#validatingadmissionpolicy](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#validatingadmissionpolicy)