Kubernetes Admission Controllers: The API's Gatekeepers

Why it exists

Kubernetes needs a way to enforce custom policies, security standards, and configuration best practices before an object is created or updated. Without this, you could only react to bad configurations after they're already running. Admission controllers provide a mechanism for proactive governance, preventing problems before they start.

The mental model

An admission controller is like a bouncer at a club's entrance, but for the Kubernetes API server. When you send a request (like kubectl apply), it first passes authentication and authorization. Then, before your object is saved to the cluster's database (etcd), it's handed to the bouncers—the admission controllers. They check your request against a set of rules. Some might modify it (a mutating controller adding a required label), while others just approve or deny it (a validating controller checking for privileged containers). Only if it passes all checks is it allowed in.

How it works

Admission control is a multi-stage process in the API server's request lifecycle. After a request is authenticated and authorized, it goes through two phases. First, it hits the mutating admission controllers. These can change the object in the request, for example, to inject a sidecar container or add default annotations. Second, the (potentially modified) object is passed to the validating admission controllers. These controllers cannot change the object but can reject the request if it violates a policy. If any controller in the chain rejects the request, the entire operation fails and the object is not persisted to etcd.

When to use it

Admission controllers are essential for cluster governance and security. Use them for enforcing security policies, such as blocking containers that run as the root user or don't specify resource limits. They are also used for automation, like automatically injecting a service mesh proxy (e.g., Istio, Linkerd) into every new pod. Finally, they enforce organizational standards, like requiring all resources to have a team label for cost allocation.

When not to use it

Do not use admission controllers for authentication or authorization. Those steps happen before admission control and are handled by other Kubernetes components like RBAC. Also, avoid performing slow, complex, or long-running operations within a controller. They are in the synchronous, critical path of API requests; a slow controller will degrade the performance of the entire cluster control plane.

One canonical example

A common use case is enforcing label requirements. A company can deploy a ValidatingAdmissionWebhook that checks every new Pod for a cost-center label. If a developer tries to create a Pod without that label, the API server passes the request to the webhook. The webhook inspects the Pod's metadata, sees the label is missing, and returns a rejection. The API server then denies the request, and the developer's kubectl apply command fails with an error explaining the policy violation.