Wednesday 1 July 2026, 02:03 PM

Kubernetes 1.36 eliminates webhook latency with native CEL mutation policies

Kubernetes 1.36 introduces Stable MutatingAdmissionPolicy, using CEL and Server-Side Apply to eliminate webhook latency and prevent fail-closed outages.

I’ve spent enough late nights debugging catastrophic cluster outages to know that "fail-closed" is a terrifying phrase when applied to your control plane. If you’ve scaled a Kubernetes environment over the last few years, you already know the architectural bottleneck that is MutatingWebhookConfiguration.

Historically, if you wanted to modify incoming API requests—say, to inject a sidecar proxy or enforce security defaults—you had to rely on an external webhook. This legacy approach meant every API request required a network hop. It meant dedicated infrastructure, complex TLS certificate management, and the constant underlying anxiety that if your webhook server crashed, your cluster could fail-closed and paralyze deployments.

With the April 2026 release of Kubernetes 1.36, the community has finally engineered a native way out. The MutatingAdmissionPolicy API (admissionregistration.k8s.io/v1) has officially reached Stable (General Availability) status, marking a fundamental shift in how resource mutations are handled natively within the cluster.

Here is a look at the implementation details and why this changes the game for cluster architecture.

Eliminating the network hop with in-process CEL

The core architectural shift in Kubernetes 1.36 is internalizing the mutation process directly within the kube-apiserver. Instead of sending payloads over the network, the API server executes declarative Common Expression Language (CEL) policies in-process.

Any time you run custom logic inside the API server, you risk hanging the process. To protect the kube-apiserver from performance degradation and thread exhaustion, the implementation of CEL used here is deliberately Turing-incomplete. It strictly restricts loops and unbounded recursion. From an engineering standpoint, this is a brilliant constraint—it guarantees that all in-process mutation expressions terminate in milliseconds. You get the flexibility of custom mutation logic without the risk of bringing down your control plane with a poorly written script.

Fixing the GitOps overwrite wars with Server-Side Apply

If you use ArgoCD or Flux, you’ve likely experienced the headache of webhook conflicts. Legacy webhooks relied on JSON Patch, which blindly overwrote fields. This constantly triggered GitOps controllers to detect drift and revert the changes, resulting in endless reconciliation loops and spiked API server load.

A critical technical breakthrough in the 1.36 release is how MutatingAdmissionPolicy integrates with Server-Side Apply (SSA) merge algorithms. By utilizing the ApplyConfiguration mutation mode, your CEL expressions construct partial objects that merge cleanly with incoming requests. Because this respects field ownership natively, it completely resolves historical conflicts with GitOps controllers. The mutation happens, the fields are merged intelligently, and ArgoCD doesn't lose its mind trying to revert a blindly patched JSON payload.

Dynamic configuration and blast radius containment

Hardcoding values into policies doesn't scale when you are managing fleets of clusters. The new architecture supports Parameter Resources, which allows a single CEL policy to dynamically pull variables—such as specific image tags, environment variables, or resource limits—from separate Kubernetes objects like ConfigMaps or Custom Resource Definitions referenced in the Binding. You can write the policy once and dynamically reconfigure its behavior per namespace or environment just by updating a ConfigMap.

Furthermore, the Kubernetes maintainers anticipated the footguns. Kubernetes 1.36 includes hardcoded self-protection safeguards that prevent a MutatingAdmissionPolicy from mutating other MutatingAdmissionPolicy or MutatingAdmissionPolicyBinding objects via the REST API. This effectively neutralizes the risk of creating unrecoverable, recursive cluster states where a policy accidentally mutates itself into a broken loop.

The reality of adoption and the 80/20 rule

Major managed cloud providers aren't waiting around on this one. Amazon EKS and Google Kubernetes Engine (GKE) have already rolled out support for Kubernetes 1.36 and are enabling these native CEL-based policies by default for new clusters. We are also seeing rapid adoption from ecosystem heavyweights like Kyverno and OPA Gatekeeper, driven by the operational simplicity and developer-friendly nature of CEL compared to Rego.

Are custom webhooks entirely dead? Not quite. For the 10-20% of edge cases that strictly require external HTTP calls—like querying an external IPAM database for an IP address before admitting a pod—you will still need a traditional webhook.

But for the vast majority of standard use cases, native MutatingAdmissionPolicy is poised to completely obsolete the traditional webhook. We are looking at faster, highly resilient, and significantly more cost-effective Kubernetes environments, all by stripping out a network hop we never really wanted in the first place.