1. The Last Gate Before a Resource Is Written to etcd — What Is Admission Control?
MutatingAdmissionPolicy, which reached GA in Kubernetes v1.36, changes how this "layer that decides what state to accept" works. At the core of Kubernetes sits a simple mechanism: it continuously compares the desired state against the actual state and automatically corrects any difference. Tell a Deployment "I want 10 Pods running," and Kubernetes keeps making that true. But for that mechanism to work at all, there has to be a layer that decides "what counts as an acceptable desired state in the first place." That layer is admission control.
Right before a Pod is written to etcd, the API server runs two checks: it mutates the resource during mutating admission, then validates it during validating admission. This order and mechanism are documented in the official Kubernetes documentation. Automatic label injection, default value assignment, and sidecar container injection all happen during this mutating admission stage.
For a long time, the only way to customize this stage was a Mutating Admission Webhook. In 2026, something changed that assumption at the core of Kubernetes itself: MutatingAdmissionPolicy.
2. The Operational Cost of Mutating Webhooks — Certificates, Network Hops, Availability
If your team has ever run a Mutating Webhook in-house, you already know the operational cost. According to the official Kubernetes documentation, a WebhookConfiguration requires a PEM-formatted, Base64-encoded CA certificate (caBundle), and the server certificate must be valid for <svc_name>.<svc_namespace>.svc. If that certificate expires, the webhook itself stops functioning.
On top of that, if you run the webhook server as a Deployment inside the cluster, your team also has to guarantee that Pod's own availability. Depending on the combination of timeout setting (10 seconds by default) and failurePolicy (Fail or Ignore), a webhook server outage can block Pod creation entirely. The official documentation itself warns that "admission webhooks are inherently part of the cluster control plane and must be built and deployed with great care in production."
In short, a Mutating Webhook is a system that keeps you carrying three ongoing operational debts: certificate management, a network hop, and availability assurance.
3. What MutatingAdmissionPolicy Changes — In-Process Mutation with CEL
MutatingAdmissionPolicy was proposed as KEP-3962, moved through alpha in v1.32 and beta in v1.34, and reached GA (stable) in v1.36. The official Kubernetes v1.36 release post also confirms that both ValidatingAdmissionPolicy and MutatingAdmissionPolicy are now enabled by default.
The mechanism itself is simple. According to the official Kubernetes documentation, a MutatingAdmissionPolicy setup consists of three resources:
- MutatingAdmissionPolicy: defines the abstract mutation logic as a CEL expression
- Parameter resource (optional): supplies configuration values via a ConfigMap, CRD, etc.
- MutatingAdmissionPolicyBinding: links the policy to its parameters and defines the applicable scope (which resource types it targets, etc.)
Sidecar injection, for example, can be expressed with a CEL expression like this:
mutations:
- patchType: "ApplyConfiguration"
applyConfiguration:
expression: >
Object{
spec: Object.spec{
initContainers: [
Object.spec.initContainers{
name: "mesh-proxy",
image: "mesh/proxy:v1.0.0"
}
]
}
}
No external service, no certificate. The CEL expression is evaluated directly inside the API server, and the network hop disappears entirely. The CNCF blog makes the same point: "while external tools depend on network calls, CEL is embedded directly in the API server, which reduces latency and improves reliability." CEL expressions have no loops or recursion, so they run in linear time, and since v1.32 a cost estimator has also prevented the API server from being overloaded.
Teams migrating from an existing Mutating Webhook also have a JSON Patch strategy available alongside ApplyConfiguration, which makes it easier to port existing webhook logic over directly.
4. How Far Can You Replace It with CEL? A Decision Framework
The thing not to misunderstand here is that MutatingAdmissionPolicy is a "replacement," not a "total elimination," of webhooks. The decision comes down to two axes.
Cases where you should move to CEL
- Attaching a fixed label or annotation
- Setting a default value on a field
- Adding a sidecar after checking whether an existing container is already present (
matchConditionsprevents duplicate injection)
These can all be expressed declaratively and don't need to reference external state.
Cases where you should keep the webhook
- Mutations that require querying an external database or API
- Complex logic involving consistency checks across multiple external systems
- Procedural processing that CEL expressions simply can't express
Kyverno itself is navigating this same boundary in its own migration. According to Nirmata's blog, Kyverno is phasing out its legacy pattern-based ClusterPolicy (deprecated as of v1.17, scheduled for removal in v1.20) and moving to five new CEL-based API types, including MutatingPolicy. The article notes that "CEL is the same expression language Kubernetes itself uses for ValidatingAdmissionPolicy," meaning that learning CEL for Kyverno builds skills that carry over across the whole Kubernetes governance tooling landscape.
This same new capability also runs on plain Kubernetes API machinery, so on an environment like K3s-based Kubo you don't have to wait on any distribution-specific support — it's available as a standard Kubernetes feature.
5. Making the Migration Call and Taking Practical Steps on K3s
As the official K3s site puts it, K3s is a "certified Kubernetes distribution for IoT & Edge computing," packaged as a single binary under 70MB that bundles the standard Kubernetes API as-is. Per the K3s release notes, the K3s v1.36 line is based on Kubernetes v1.36, so MutatingAdmissionPolicy is available on K3s too as a plain Kubernetes feature — no vendor-specific restrictions or extra setup required.
A sensible way to approach the migration: first inventory your existing Mutating Webhooks and sort them into what can be expressed declaratively — fixed label assignment, default value setting, simple sidecar injection — versus logic that depends on complex external state. Migrate the first group to MutatingAdmissionPolicy in stages, scope it down with matchConditions, and verify the impact on existing resources with a dry-run-style failurePolicy: Ignore setting before rolling it out to production.
On an environment like Kubo, which runs the standard Kubernetes API as-is since it's K3s-based, you can adopt new features like this with no special handling required. Because it doesn't insert a proprietary layer the way EKS or AKS does, one advantage of a K3s-based platform is that you get upstream Kubernetes' evolution directly.
For teams that have been burned by certificate expirations or Pod availability issues while running Mutating Webhooks, the inventory-and-phased-migration process itself can feel like yet another chore. With Kubo Cloud's Captain UI, you can visualize which resources have which admission policies applied and what changes they're making as you work through the migration. If you'd rather not roll out policies to production as a black box, feel free to reach out via Contact Us.
6. Summary
MutatingAdmissionPolicy resolves the three ongoing operational debts that Mutating Webhooks have carried — certificate management, a network hop, and availability assurance — by replacing them with a declarative CEL expression. But that's a division of labor, not total elimination: simple declarative changes move to CEL, while complex mutations that depend on external state stay on webhooks.
Since K3s is a standard Kubernetes distribution, you can use this feature as-is on v1.36 and later. The full MutatingAdmissionPolicy specification is laid out in the official documentation, so it's worth a read before you migrate. Start by taking inventory of your existing Mutating Webhooks and figuring out how far you can move to CEL. If you want to keep using full-fledged Kubernetes capabilities while cutting operational overhead, K3s-based Kubo is one option worth considering — it's worth a look if you want the power of EKS/AKS with the ease of something like Vercel.
For a deeper dive into related admission control topics, see what happened when we migrated to ValidatingAdmissionPolicy and our comparison of Kyverno and OPA Gatekeeper.