What are Kubernetes Admission Controllers?
Learn how Kubernetes admission controllers mutate and validate API requests before etcd persistence, with a real webhook config example.
Expected Interview Answer
Admission controllers are plugins that intercept requests to the Kubernetes API server after authentication and authorization but before an object is persisted to etcd, and they can either mutate the request or validate it and reject it outright.
The request pipeline runs mutating admission webhooks first, which can modify the object — for example injecting a sidecar container or setting default resource limits — and then runs validating admission webhooks, which can only accept or reject the now-mutated object, never change it further. Built-in controllers like NamespaceLifecycle, LimitRanger, and ResourceQuota ship compiled into the API server binary and are enabled or disabled by flag, while dynamic admission uses a MutatingWebhookConfiguration or ValidatingWebhookConfiguration object that points at an external HTTPS service you run yourself. Because every create, update, and delete for the configured resources and namespaces is routed through these webhooks synchronously, a slow or unavailable webhook server can block cluster operations entirely, which is why `failurePolicy` and `timeoutSeconds` are critical safety knobs. Tools like OPA Gatekeeper and Kyverno are built entirely as validating (and sometimes mutating) admission webhooks that enforce organization-wide policy such as “every pod must set resource limits” or “images must come from an approved registry”.
- Enforces org-wide policy before objects ever reach etcd
- Enables automatic defaulting and sidecar injection
- Blocks non-compliant workloads at the API boundary, not after the fact
- Decouples policy logic from the core API server via webhooks
AI Mentor Explanation
An admission controller is like the match referee checking every player’s kit and paperwork at the boundary rope before they are allowed onto the field, not after the toss has already happened. A mutating check might quietly swap an illegal bat for a legal one from the team box, while a validating check afterward can only wave the player through or send them back to the pavilion. If the referee’s checking table is slow, the entire start of play is delayed for both teams. Tournaments add extra referees, like anti-doping officers, as additional validation steps beyond the basic kit check.
Step-by-Step Explanation
Step 1
Request passes authn/authz
The API server first authenticates the caller and checks RBAC permissions for the requested action.
Step 2
Mutating admission runs
Built-in and webhook mutating controllers can modify the object, e.g. injecting defaults or a sidecar.
Step 3
Object schema validation
The mutated object is validated against the OpenAPI schema for that resource kind.
Step 4
Validating admission runs
Validating controllers/webhooks accept or reject the final object; on accept it is persisted to etcd.
What Interviewer Expects
- Distinction between mutating and validating admission phases and their ordering
- Knowledge that admission runs after authn/authz but before etcd persistence
- Awareness of failurePolicy/timeoutSeconds risk for webhook availability
- Familiarity with policy engines like OPA Gatekeeper or Kyverno as webhook implementations
Common Mistakes
- Confusing admission control with RBAC authorization
- Assuming validating webhooks can also mutate the object
- Forgetting a hung webhook can block all matching API requests cluster-wide
- Not knowing built-in controllers are compiled into the API server, unlike dynamic webhooks
Best Answer (HR Friendly)
“Admission controllers sit right at the front door of the Kubernetes API server, after it has confirmed who you are and what you are allowed to do, but before anything is actually saved. They can quietly fix up a request, like adding default resource limits, or they can flat-out reject it if it breaks policy, which is how we enforce things like “every image must come from our approved registry” cluster-wide.”
Code Example
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: require-resource-limits
webhooks:
- name: limits.policy.example.com
clientConfig:
service:
name: policy-webhook
namespace: policy-system
path: /validate-pod-limits
rules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["pods"]
failurePolicy: Fail
timeoutSeconds: 5
sideEffects: None
admissionReviewVersions: ["v1"]Follow-up Questions
- What is the difference between a mutating and a validating admission webhook?
- What happens to API requests if a webhook with failurePolicy Fail becomes unreachable?
- How would you use OPA Gatekeeper to enforce a naming convention on namespaces?
- Why can admission webhooks introduce a chicken-and-egg problem during cluster bootstrap?
MCQ Practice
1. When do admission controllers run in the API request pipeline?
Admission control runs after authn/authz succeed and before the object is written to etcd, letting it mutate or reject the request.
2. What can a mutating admission webhook do that a validating webhook cannot?
Mutating webhooks can alter the incoming object; validating webhooks only accept or reject the final, already-mutated object.
3. What risk does failurePolicy: Fail on an admission webhook introduce?
With failurePolicy Fail, an unreachable or slow webhook causes the API server to reject the matching requests, which can block cluster operations.
Flash Cards
What is an admission controller? — A plugin that intercepts API requests after authn/authz to mutate or validate objects before persistence.
Mutating vs validating admission order? — Mutating webhooks run first and can change the object; validating webhooks run after and only accept/reject.
How is dynamic admission configured? — Via MutatingWebhookConfiguration / ValidatingWebhookConfiguration pointing at an external HTTPS service.
Name two policy engines built as admission webhooks? — OPA Gatekeeper and Kyverno.