CEL policy expressions, hands-on

The policy language that lives inside the thing it governs

Common Expression Language is deliberately small. It is not Turing complete, it has no side effects, and every expression is guaranteed to terminate. Those three properties sound like limitations, and they are exactly why CEL is everywhere: if evaluation cannot loop forever and cannot reach out to the network, it is safe to run inside a hot path.

So CEL runs where a general-purpose policy engine cannot. It is embedded in the Kubernetes API server itself, in Google Cloud IAM's condition evaluator, in Envoy, in Firebase security rules, and in CRD field validation. There is no sidecar, no webhook, no extra network hop, and nothing to be unavailable at the moment a decision is needed.

That is the real contrast with OPA and Rego, and it is worth having a clear view of it because the two are increasingly presented as alternatives:

• Rego is a full policy language evaluated by a separate engine. It can join across documents, load external data, and express arbitrarily complex logic. It costs you a component to deploy, secure, and keep available.
• CEL is an expression evaluated in-process by the host. It cannot do joins or fetch data. It also cannot be down, cannot add latency you did not already have, and cannot be bypassed by a network failure.

For "no privileged containers in this namespace", CEL is straightforwardly the better answer now that it is built in. For "no image outside our registry unless the team owns a documented exception recorded in this other system", it is the wrong tool and no amount of cleverness fixes that.

Expressions, macros, and the activation

A CEL policy is one expression that evaluates to a boolean. There is no statement sequence, no assignment, no early return, and no function you define yourself. If you are reaching for those, you have hit the ceiling and should be looking at a different layer.

Iteration exists, but only through macros, and only bounded by a collection you already have:

• list.all(x, predicate) is true when every element satisfies the predicate.
• list.exists(x, predicate) is true when at least one does.
• list.exists_one(x, predicate) is true when exactly one does.
• list.filter(x, predicate) returns the matching elements; wrap in size() to count them.
• list.map(x, expression) transforms each element.
• has(x.field) tests presence, which is not the same as testing truth.

That last one is the thing to internalise first. Reading a field that is not there is an error in CEL, not a false and not a null. An error propagates and the whole expression fails, which in Kubernetes admission means the policy's failurePolicy decides your fate. has() before you dereference an optional field is not defensive style, it is the difference between a working policy and one that fails open or blocks every deployment.

# Errors, if any container omits securityContext:
object.spec.containers.all(c, c.securityContext.runAsNonRoot == true)

# Correct: presence-check first. && short-circuits, so the right-hand
# side is never evaluated when has() is false.
object.spec.containers.all(c,
  has(c.securityContext) && c.securityContext.runAsNonRoot == true)

Walk-through

1. Get an evaluator you can iterate in

Writing CEL by pushing YAML at a cluster and reading admission errors is a miserable loop. Evaluate expressions locally first.

mkdir -p ~/cel-lab && cd ~/cel-lab
pip3 install cel-python

cat > pod.json <<'EOF'
{"object": {"metadata": {"name": "web", "labels": {"team": "payments"}},
 "spec": {"replicas": 7,
   "containers": [
     {"name": "app", "image": "ghcr.io/acme/app:1.2.3",
      "securityContext": {"runAsNonRoot": true, "privileged": false},
      "resources": {"limits": {"cpu": "500m", "memory": "512Mi"}}},
     {"name": "sidecar", "image": "docker.io/library/busybox:latest"}
   ]}}}
EOF

cat > cel.py <<'EOF'
import sys, json, celpy
env = celpy.Environment()
doc = celpy.json_to_cel(json.load(open('pod.json')))
for src in sys.argv[1:]:
    print(f"{src}\n  -> {env.program(env.compile(src)).evaluate(doc)}\n")
EOF

python3 cel.py 'object.spec.replicas <= 5'

2. The syntax, in one pass

python3 cel.py \
  'object.metadata.name == "web"' \
  'object.spec.replicas > 5 && object.spec.replicas < 20' \
  '"team" in object.metadata.labels' \
  'object.metadata.labels["team"] == "payments"' \
  'object.metadata.name.startsWith("web")' \
  'size(object.spec.containers) == 2' \
  'object.spec.replicas > 5 ? "too many" : "ok"'

C-like, and mostly unsurprising. Strings are double-quoted or single-quoted, in tests map keys and list membership, and there is a ternary. The standard library gives you startsWith, endsWith, contains, matches (a regular expression, RE2 flavoured, so no lookaround), size, and duration and timestamp arithmetic.

3. Macros, which is where real policies live

python3 cel.py \
  'object.spec.containers.all(c, has(c.resources) && has(c.resources.limits))' \
  'object.spec.containers.exists(c, c.image.endsWith(":latest"))' \
  'object.spec.containers.map(c, c.name)' \
  'size(object.spec.containers.filter(c, !has(c.securityContext)))' \
  'object.spec.containers.all(c, c.image.startsWith("ghcr.io/acme/"))'

Run these against the sample and read the results carefully. The sidecar container has no securityContext and no resources, and pulls :latest from Docker Hub, so it fails three of the five. That is a deliberately realistic shape: the workload people wrote carefully, plus the container somebody added in a hurry.

4. Write a real ValidatingAdmissionPolicy

This is native Kubernetes admission control, generally available since Kubernetes 1.30. No webhook, no controller, no certificate rotation.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "require-resource-limits.csoh.org"
spec:
  # Fail = an error evaluating the policy denies the request.
  # Ignore = an error lets it through. Choose deliberately.
  failurePolicy: Fail

  # Coarse filter: which API objects this policy is even considered for.
  matchConstraints:
    resourceRules:
      - apiGroups:   ["apps"]
        apiVersions: ["v1"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["deployments"]

  validations:
    - expression: >-
        object.spec.template.spec.containers.all(c,
          has(c.resources) && has(c.resources.limits) &&
          has(c.resources.limits.memory))
      message: "every container must set a memory limit"

    - expression: >-
        object.spec.template.spec.containers.all(c,
          !c.image.endsWith(":latest"))
      message: "image tags must be pinned; :latest is not a version"

The policy on its own does nothing. It needs a binding, and the separation is the good part: one policy, several bindings, each scoped differently and each choosing its own enforcement strength.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "require-resource-limits-prod.csoh.org"
spec:
  policyName: "require-resource-limits.csoh.org"
  # Deny | Warn | Audit. Warn and Audit can be combined; Deny stands alone.
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: production
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "require-resource-limits-dev.csoh.org"
spec:
  policyName: "require-resource-limits.csoh.org"
  validationActions: [Warn, Audit]   # same rule, observe-only in dev
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: development

That two-binding pattern is how you roll a policy out without an outage. Bind it as [Warn, Audit] everywhere first, read the audit log for a week to find out what it would have blocked, and only then add a Deny binding scoped to the namespaces you have cleaned up.

5. Try it on a throwaway cluster

kind create cluster --name cel-lab       # any recent Kubernetes; VAP is GA in 1.30+
kubectl apply -f policy.yaml

kubectl create namespace prod
kubectl label namespace prod environment=production

# Should be rejected, with your message
kubectl -n prod create deployment bad --image=nginx:latest

kind delete cluster --name cel-lab

6. Two other places the same expressions turn up

CRD field validation. The same CEL, attached to a schema, so an invalid custom resource is rejected on write with no controller involved:

openAPIV3Schema:
  type: object
  properties:
    spec:
      type: object
      properties:
        retentionDays: { type: integer }
        tier:          { type: string }
      x-kubernetes-validations:
        - rule: "self.tier != 'archive' || self.retentionDays >= 365"
          message: "archive tier requires at least 365 days retention"
        # self.oldSelf is available for transition rules on update
        - rule: "self.retentionDays >= oldSelf.retentionDays"
          message: "retention may be increased but never reduced"
          optionalOldSelf: false

Google Cloud IAM conditions. Same language, completely different variables, and a genuinely useful control:

# Grant applies only during a maintenance window, and only to one bucket.
request.time < timestamp("2026-09-01T00:00:00Z") &&
resource.type == "storage.googleapis.com/Bucket" &&
resource.name.startsWith("projects/_/buckets/acme-backups")

Time-bound IAM grants are one of the highest-value, least-used features in Google Cloud, and they are a CEL expression in a text box. The same instinct works for AWS through IAM condition keys and for Azure through ABAC conditions, though neither of those uses CEL.

7. The authorizer variable

Kubernetes admission hands your expression an authorizer, which lets a policy ask the API server's own RBAC a question. This is unusual and worth knowing about, because it lets you write "this is allowed, but only for principals who already hold a specific permission" without maintaining a parallel list of who those are.

validations:
  - expression: >-
      !object.spec.template.spec.hostNetwork ||
      authorizer.group('policy.csoh.org').resource('hostnetwork')
                .check('use').allowed()
    message: "hostNetwork requires the hostnetwork/use permission"

The privilege becomes an ordinary RBAC grant on a virtual resource, which means it is granted, reviewed, and audited by the same machinery as everything else, rather than by an annotation somebody added to a namespace two years ago.

Hands-on exercises

Run these with the cel.py harness and pod.json from step 1.

python3 cel.py 'object.spec.containers.all(c,
  has(c.securityContext) &&
  c.securityContext.runAsNonRoot == true &&
  (!has(c.securityContext.privileged) || c.securityContext.privileged == false))'

validations:
  - expression: >-
      object.spec.replicas >= oldObject.spec.replicas
    message: "replica count may not be reduced"

# Guard inside the expression
- expression: >-
    oldObject == null || object.spec.replicas >= oldObject.spec.replicas

# Or keep the expression clean and narrow matchConstraints to UPDATE only
matchConstraints:
  resourceRules:
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      operations: ["UPDATE"]      # CREATE never reaches this policy
      resources: ["deployments"]

deny contains msg if {
    some c in input.request.object.spec.containers
    not startswith(c.image, "ghcr.io/acme/")
    msg := sprintf("image %v is not from the approved registry", [c.image])
}

validations:
  - expression: >-
      object.spec.containers.all(c, c.image.startsWith("ghcr.io/acme/"))
    message: "all images must come from ghcr.io/acme/"

Common mistakes

• Dereferencing an optional field without has(). The result is an error, and what happens next is decided by failurePolicy rather than by you.
• Choosing failurePolicy by accident. Fail turns a typo into a cluster-wide outage; Ignore turns it into a control that silently is not there. Both are defensible; neither should be a default you never looked at.
• Going straight to Deny. Bind as [Warn, Audit], read what it would have blocked, then enforce.
• Assuming oldObject exists. It is null on CREATE. Guard it or restrict the operations you match.
• Writing a policy with no binding. A ValidatingAdmissionPolicy alone does nothing at all, and nothing warns you. It looks deployed.
• Expecting PCRE in matches(). It is RE2, so no lookahead, no lookbehind, no backreferences. Same constraint the regex page covers.
• Hardcoding lists in expressions. Use paramKind and params so the list is a reviewable cluster object.
• Ignoring the cost budget. Kubernetes bounds how expensive an expression may be and rejects ones that exceed it. Deeply nested macros over large collections are the usual cause, and the rejection happens when you apply the policy, not when it runs.