Understanding a Kubernetes Admission Controller
An admission controller is a piece of code that intercepts requests to the Kubernetes API server after authentication and authorization but before an object is persisted to etcd. Admission controllers can validate a request (accept or reject it outright) or mutate it (modify the object before it’s saved), giving cluster operators a way to enforce policy and inject defaults on every object created or updated in the cluster, not just Pods.
How Admission Control Works
Kubernetes ships with a set of built-in admission controllers compiled into the API server (such as NamespaceLifecycle, LimitRanger, and ResourceQuota) that are enabled via the –enable-admission-plugins flag. Beyond built-ins, the two most important controllers for extensibility are MutatingAdmissionWebhook and ValidatingAdmissionWebhook, which let the API server call out to external HTTP services for custom logic. Mutating webhooks run first and can modify a request – for example, injecting a sidecar container or setting default resource limits – and validating webhooks run after, deciding to accept or reject the (possibly mutated) object. Tools like Open Policy Agent’s Gatekeeper and Kyverno are built entirely on this webhook mechanism to implement policy-as-code.
Simple Example
A platform team wants to block any Pod from running as root and require every image to come from an approved internal registry. They deploy Gatekeeper, which registers a ValidatingAdmissionWebhook with the API server, and define policies as Kubernetes-native custom resources. When a developer applies a Deployment whose Pod spec sets runAsNonRoot to false or references an unapproved image, the API server forwards the request to Gatekeeper’s webhook during admission, the policy evaluates it and returns a deny response, and the API server rejects the request with an explanatory error before the object is ever written to etcd – the noncompliant Pod is never created in the first place.
Common Use Cases
Security Policy Enforcement
Blocking privileged containers, enforcing Pod Security Standards, requiring specific labels, or restricting image registries.
Automatic Defaults and Injection
Mutating webhooks are how service meshes like Istio and Linkerd automatically inject sidecar proxies into Pods without developers editing manifests themselves.
Resource Governance
Built-in controllers like ResourceQuota and LimitRanger enforce that every namespace stays within defined CPU and memory budgets and every container gets sane default requests and limits.
Benefits
- Enforces policy centrally and consistently, catching violations before they ever reach the cluster rather than relying on after-the-fact detection.
- Enables automation like sidecar injection, default labeling, and configuration standardization without changing every team’s manifests.
- Extensible through webhooks, so organizations can implement custom governance (policy-as-code) without modifying Kubernetes itself.
Limitations and Risks
- A misconfigured or unavailable webhook with failurePolicy set to Fail can block all matching API requests cluster-wide, including critical system objects, if the webhook service goes down.
- Webhooks add latency to every API request they intercept, and poorly performing webhook services can slow down the entire cluster’s API responsiveness.
- Mutating webhooks that silently change objects can surprise engineers who expect what they submitted to be exactly what’s stored – visibility and documentation matter.
- Ordering and interaction between multiple webhooks can be difficult to reason about, especially when several mutating webhooks modify overlapping fields.
Best Practices
- Set failurePolicy to Ignore for non-critical webhooks, and reserve Fail for policies where rejecting-by-default is genuinely safer than allowing through.
- Scope webhooks narrowly using namespaceSelector and objectSelector so they only intercept relevant requests, reducing blast radius and latency impact.
- Exclude kube-system and other critical namespaces from custom admission webhooks to avoid accidentally blocking cluster-critical components.
- Monitor webhook latency and error rates as part of overall API server health, since they sit directly in the request path.
- Prefer established policy engines like OPA Gatekeeper or Kyverno over hand-rolled webhook services for easier maintenance and community-vetted policy libraries.
Frequently Asked Questions
What is Kubernetes Admission Controller?
An admission controller intercepts Kubernetes API requests after authentication and authorization but before persistence, validating or mutating objects to enforce cluster policy.
How does Kubernetes Admission Controller work?
Kubernetes Admission Controller works by combining the components described in the sections above. The main page walks through the architecture, the typical use cases, and the trade-offs to weigh before adopting it.
Why does Kubernetes Admission Controller matter?
Teams adopt Kubernetes Admission Controller to ship faster, run more reliably, and reduce the cognitive load on engineers. The benefits, limits, and adjacent tools are covered in the body above.
When should you use Kubernetes Admission Controller?
Use Kubernetes Admission Controller when the problems it solves match what your team is hitting today. The page above outlines the signals that mean you should adopt it now, and the cases where a simpler approach is fine.
