Admission controller
An admission controller is a component that intercepts requests to the Kubernetes API server after authentication and authorisation but before the object is persisted, and can reject or modify them. It is the point where a cluster policy is actually enforced rather than merely documented.
Two kinds exist and the difference matters when reading a configuration. A mutating controller changes the object on its way through, for example injecting a sidecar or setting a default security context. A validating controller only accepts or rejects. Mutation runs first, so a policy that validates a field another controller rewrites afterwards is checking the wrong version of the object.
This is what stops a pod requesting host level privileges, a mounted host path, or a host network namespace, which are the configurations that turn an application compromise into a container escape. Without enforcement at admission, those requests are granted by the scheduler because nothing in the cluster is looking.
The failure modes we test for are consistent. A webhook configured to fail open, so that a policy engine which is unavailable or overloaded silently permits everything. Namespaces excluded from policy for operational reasons and then used for ordinary workloads. Policies that cover pods and not the controllers that create pods, so the same specification arrives through a deployment untouched. And a service account with rights to modify the policy configuration itself, which collapses the whole control into one permission. Verifying that a cluster’s Kubernetes security policy holds against a deliberately non-compliant workload is part of the cloud testing where we try to get a workload past the policy.