Admission control has matured into the boring middle of the Kubernetes platform, which is exactly what defenders want. The patterns that survived four years of production use are now well-understood, the failure modes are documented, and the tooling has converged on a small set of viable choices. This post catalogues the patterns that platform teams should still be running in 2026, the ones that have aged poorly, and the ones that are newly relevant because of recent API changes.
Kubernetes 1.32 made ValidatingAdmissionPolicy generally available, and 1.33 followed with MutatingAdmissionPolicy in beta. Those changes alter the calculus for several patterns we used to handle through external webhooks. The shift is not total, but it is meaningful, and any platform team that has not revisited their admission strategy since 1.30 is probably running more webhook infrastructure than they need.
What belongs in a validating webhook now?
Validating webhooks remain the right place for policy decisions that need to call out to external state. Image signature verification against a remote keyless transparency log, organization-wide policy lookups against a central service, and SBOM-attestation freshness checks all justify the webhook latency and operational cost. These patterns share a property: the policy data lives outside the cluster and changes on a different cadence than cluster state.
What belongs in CEL-based ValidatingAdmissionPolicy now is anything that can be expressed as a pure function of the request object. Required labels, image registry allowlists, resource limit floors, hostPath bans, privileged container bans, and most of the Pod Security Standards enforcement fit cleanly. The latency improvement is real: in-process CEL evaluation runs in microseconds versus tens of milliseconds for a webhook round trip, and you eliminate the webhook availability dependency that has historically caused cluster outages when the policy engine wedges.
How should image policy be structured?
Image policy is the single most leveraged admission control because every workload passes through it. The pattern that works is layered: a CEL policy at the API server level handles registry allowlists and tag-versus-digest enforcement, and a webhook handles signature verification and attestation policy because those require external lookups. Keep the CEL layer fast and unconditional, and let the webhook layer fail open or closed based on your risk tolerance for the specific class of attestation.
The pattern that has aged poorly is doing everything in one webhook. Teams that built monolithic image policy webhooks in 2023 and 2024 are now dealing with deployments that wedge because their policy engine cannot keep up with autoscaling events. The cost of a single webhook timeout is amplified when it sits in the critical path of every pod creation. Split the fast-and-local checks from the slow-and-remote checks, and you get both better latency and a smaller blast radius when the remote dependency fails.
When are mutating webhooks still worth it?
Mutating webhooks should be used sparingly. The cases that still justify them in 2026 are sidecar injection for service mesh and observability, automatic secret reference rewriting for centralized secret management, and image digest pinning where a tag is resolved to its current digest at admission time. Each of these provides a real platform benefit that would be expensive or error-prone to push back onto application teams.
What you should not be doing with mutating webhooks is enforcing security defaults like dropping capabilities or setting readOnlyRootFilesystem. Pod Security Standards at the namespace level cover most of this without the operational cost of a webhook, and the few gaps can be closed with validating policy that rejects non-compliant manifests rather than silently mutating them. The silent mutation pattern hides intent from application teams and makes incident debugging harder. Reject loudly, do not fix quietly.
What about policy bundles and reusability?
The reusability story improved significantly in the last year. Both Kyverno and OPA Gatekeeper now ship curated policy bundles aligned to CIS benchmarks, NIST SP 800-190, and the SLSA build requirements, and those bundles are versioned and signed. Pulling a vendor-maintained bundle for the boring 80% of policies frees your platform team to write the 20% that is specific to your environment. Treat the bundles like any other dependency: pin versions, review upgrades, and run them in a non-blocking audit mode for at least a release cycle before enforcing.
The anti-pattern is forking the bundle to make a small change. If you find yourself doing that, push the change upstream or write a separate policy that supplements the bundle without modifying it. Forked bundles drift, and the drift is invisible until you try to upgrade six months later and discover that nothing merges cleanly.
How do you test admission policies safely?
Test policies in three stages. First, write unit tests against the policy in isolation using the Kyverno CLI or OPA test framework. These run in CI and catch syntax and basic logic errors. Second, deploy the policy in audit-only mode to a staging cluster and run real workloads against it for at least a week to surface false positives. Third, deploy in enforce mode behind a feature flag that lets you flip back to audit-only quickly if a previously-unknown workload pattern starts failing.
The teams that get into trouble are the ones that skip stage two. Synthetic test cases miss the long tail of real manifest variation, and enforcing a policy that has not seen production traffic is how clusters get bricked at the worst possible moment. Audit-only mode is cheap; use it generously.
How Safeguard Helps
Safeguard's policy gates wrap admission control with the supply chain context that admission webhooks lack. Griffin AI evaluates whether an image's reachable CVEs cross your severity threshold, whether its SBOM is fresh enough to trust, and whether its build attestation matches your provenance requirements, before the admission decision is made. Policy gates can block pulls of unsigned images, images from suppliers with poor TPRM scores, or images whose reachable critical CVE count exceeds your zero-CVE base image budget. The integration runs in your registry and your CI pipeline, not in the admission webhook hot path, so cluster availability is not coupled to policy evaluation. You get supply chain enforcement without inheriting webhook latency or failure modes.