Kubernetes admission controllers give teams a powerful mechanism for enforcing security and operational policy before resources are ever created in a cluster. Yet many organizations underuse this capability. They rely instead on after-the-fact detection and remediation for violations that admission control could have prevented entirely.
What Admission Controllers Do
Admission controllers intercept requests to the Kubernetes API server after authentication and authorization checks pass, but before an object is persisted to etcd. This lets the controller validate or modify the request based on defined policy. It is the last checkpoint before a resource becomes real – exactly why it is such a valuable place to enforce policy. Nothing gets created that the cluster has not already agreed to allow.
Why Preventing Violations Beats Detecting Them After the Fact
Admission controllers enable a fundamentally different security posture than after-the-fact detection. Preventing a non-compliant resource from ever being created eliminates the window of exposure that detect-and-remediate approaches leave open between when a violation occurs and when someone notices and fixes it. That window can be minutes with good tooling or weeks with a manual audit process. Admission control closes it to effectively zero.
The Difference Between Validating and Mutating Admission Controllers
Kubernetes supports two kinds of admission controllers. Validating controllers approve or reject requests based on policy. Mutating controllers automatically modify requests to bring them into compliance – injecting a default resource limit, adding a required label, or stripping a disallowed field instead of rejecting the request outright. Mutating webhooks run before validating ones in the chain, so a request can be quietly corrected and then pass validation cleanly. That is convenient, but it also means developers may never learn their manifest was wrong in the first place.
Common Policies Organizations Enforce Through Admission Control
Organizations commonly use admission controllers to require resource limits on every container, block privileged container execution and host namespace sharing, disallow images from untrusted registries, require specific labels for cost allocation and ownership tracking, and enforce that containers run as non-root by default. A useful starting policy set usually covers privilege escalation prevention, image provenance, and network exposure – trying to write forty policies on day one is how these projects stall out before anything ships.
Why Policy-as-Code Tools Made Admission Control More Accessible
Policy-as-code tools built for Kubernetes admission control – Open Policy Agent with Gatekeeper, and newer options like Kyverno – have made implementing sophisticated admission policies far more accessible than writing custom admission webhook code by hand. Kyverno in particular has gained ground because its policies are written as native Kubernetes YAML instead of a separate policy language like Rego. That flattens the learning curve considerably for platform teams who are not fluent in a dedicated policy DSL.
A Rollout Pattern That Avoids Breaking Production
The safest way to introduce a new admission policy is to deploy it first in audit or dry-run mode, where violations get logged but nothing is actually blocked, and watch that log for one to two weeks before flipping enforcement on. Skipping this step is the single most common way admission control projects go badly – a policy that looks reasonable on paper turns out to block a legitimate CI pipeline or a third-party Helm chart nobody remembered used a slightly nonstandard label, and the resulting outage burns political capital that makes the next policy rollout harder to get approved.
The Testing Discipline Admission Controller Policies Require
Organizations implementing admission controller policies need to test carefully before production deployment. Overly restrictive policies can block legitimate resource creation unexpectedly. Testing new policies in a non-production cluster first – and ideally running them against a copy of real production manifests – catches most of these problems before they become an incident.
Why Admission Controllers Should Complement, Not Replace, Runtime Security
Admission control prevents policy violations at resource creation time, but does not address runtime security concerns arising after a compliant resource is already running – a container that was compliant at admission can still be compromised through an application vulnerability, or a legitimate process can still be hijacked at runtime. Tools like Falco exist precisely to cover that gap, watching syscall behavior for signs of compromise that no admission policy could have anticipated. Organizations still need runtime monitoring alongside admission control for comprehensive Kubernetes security coverage.
What Happens When the Admission Controller Itself Goes Down
A webhook-based admission controller that is unreachable can be configured to either fail open, letting requests through unchecked, or fail closed, blocking all resource creation until the webhook recovers. Fail-closed is the more secure default but it means a misbehaving webhook deployment can take down the ability to deploy anything else to the cluster, including the fix for the webhook itself – a scenario worth explicitly planning for with a documented emergency bypass procedure rather than discovering it during an incident.
Building Admission Control Into Standard Kubernetes Security Practice
Organizations running Kubernetes in security-sensitive environments should implement admission controllers to enforce their key security policies. Preventive enforcement at admission time provides meaningfully stronger assurance than relying purely on after-the-fact detection and remediation of violations that could have been prevented in the first place.