Kubernetes Webhook matchConditions CEL Filtering Prompt
Use CEL matchConditions on admission webhook configurations to skip irrelevant requests before they ever reach your webhook server, cutting latency and blast radius.
- Target user
- Engineers operating admission webhooks at scale
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Kubernetes engineer who has watched an admission webhook add 40ms to every apiserver write because it matched far more requests than it needed to. I want to add CEL `matchConditions` to a webhook so the apiserver filters requests before invoking the webhook server. I will provide: - The current `ValidatingWebhookConfiguration` or `MutatingWebhookConfiguration` - What the webhook actually cares about (which kinds, namespaces, users, label values) - The `failurePolicy` and current `objectSelector` / `namespaceSelector` Your job: 1. **Explain the layering**: `rules` and selectors filter coarsely by GVR/namespace/labels; `matchConditions` (CEL, evaluated by the apiserver) filter finely by request content AFTER selectors pass but BEFORE the webhook is called. A request must match ALL matchConditions. 2. **Identify what to push down**: any check the webhook does only to immediately return "allowed" is a candidate for a matchCondition — system service accounts, kube-system, dry-run requests, objects already carrying the right label. 3. **Write the CEL expressions** using the available variables (`object`, `oldObject`, `request`, `authorizer`, `namespaceObject`), e.g. skip the `kube-system` namespace, skip the webhook's own service account, skip `request.dryRun`. 4. **Cover the failurePolicy interaction**: matchConditions that error are treated per `failurePolicy` — explain why a `Fail` policy plus a brittle CEL expression can block all writes, and keep expressions side-effect-free and total. 5. **Show before/after**: the webhook config with matchConditions added, plus the lines of webhook server code those conditions now make dead (so they can be removed or kept as defense-in-depth). 6. **Mark DESTRUCTIVE** any change that widens what the webhook intercepts, and warn that an over-broad `Fail` webhook can lock the cluster. Output format: the layering explanation, the annotated YAML, then a short CEL test plan. Validate expressions against the documented variable set; do not apply to a live config. --- Current webhook config: ```yaml [PASTE] ``` What it actually cares about: [DESCRIBE] failurePolicy / selectors: [DESCRIBE]
Why this prompt works
Admission webhooks sit on the apiserver write path, so anything that makes them fire more often than necessary taxes every create and update in the cluster. Teams often discover their webhook is being invoked for kube-system, for their own controller’s service account, and for dry-run requests it always allows — wasted round-trips that add latency and widen the blast radius if the webhook server has a bad day. matchConditions let the apiserver evaluate CEL and drop those requests before the webhook is ever called, but few people know the feature exists or how it layers on top of selectors.
This prompt works because it forces the distinction between coarse selectors (rules, namespaceSelector, objectSelector) and fine CEL filtering, and it specifically hunts for the “webhook checks X only to immediately allow” pattern that should move into a matchCondition. The failurePolicy section is essential: a Fail webhook with a brittle CEL expression is one of the few ways to lock yourself out of writing to the cluster, so the prompt demands total, side-effect-free expressions and a test plan before anything touches a live config.
It keeps the assistant honest by asking it to mark which webhook-server code becomes dead once a condition moves to the apiserver, giving you a concrete, reviewable diff. For the policy-only alternative that needs no webhook server at all, see the ValidatingAdmissionPolicy guides and the rest of the prompt library.
Related prompts
-
Kubernetes Admission Webhook Debug Prompt
Diagnose admission webhook failures — timeout, TLS cert errors, mutating/validating semantics, failure policy traps, cluster-wide outages from webhook misconfig.
-
Kubernetes Mutating Webhook & Sidecar Injection Design Prompt
Design a production-grade MutatingAdmissionWebhook for sidecar/init injection — namespace opt-in, idempotency, failurePolicy, cert rotation, and ordering so you never double-inject or deadlock the control plane.
-
Kubernetes ValidatingAdmissionPolicy (CEL) Authoring Prompt
Replace heavyweight admission webhooks with in-process CEL ValidatingAdmissionPolicy — write expressions, bind to namespaces, version safely, and roll out from audit to deny without breaking deploys.