Kubernetes Admission Controllers & Webhooks – The Hidden Gatekeepers of Your Cluster

rjshk013 October 3, 2025

When we talk about Kubernetes, most of us immediately think of Pods, Deployments, or Services. But beneath the surface, Kubernetes has powerful gatekeepers that decide what’s allowed into the cluster and what gets modified before persistence. These are called Admission Controllers, and they often work alongside Webhooks.

Let’s break it down step by step.

🚪 What are Admission Controllers?

Admission Controllers are plug-ins inside the Kubernetes API Server.

Every time you send a request (kubectl apply, kubectl create, etc.), it flows through:

👉 Authentication → Authorization → Admission Controllers → etcd (persistence).

Their job is to validate or mutate requests before they are stored.
Think of them as security and policy gatekeepers.

Example:

Prevent pods from running as root.
Inject sidecars automatically.
Enforce resource limits.

🧩 Types of Admission Controllers

Validating Admission Controllers – Allow or reject requests.
Example: Deny creating pods without required labels.
Mutating Admission Controllers – Modify requests before they’re saved.
Example: Auto-adding default resource limits to pods.

🌐 Role of Webhooks in Admission Controllers

Not everything can be handled by built-in controllers. That’s where Admission Webhooks come in.

MutatingAdmissionWebhook and ValidatingAdmissionWebhook let you connect external services to your API server.
When a request comes in, the API server calls your webhook service over HTTPS.
Your webhook then decides:
- ✅ Allow (with or without modifications)
- ❌ Deny (reject the request)

This makes Kubernetes highly extensible, enabling custom policies.

⚙️ Are Admission Controllers Mandatory?

Yes – some are always enabled (e.g., NamespaceLifecycle, ServiceAccount).
Others are optional, and you can configure them in the API server.
Webhooks are not mandatory but are extremely common in enterprise clusters for security and compliance (OPA/Gatekeeper, Kyverno, custom sidecar injection).

🏛️ Where Do Admission Controllers Fit in Kubernetes Architecture?

Admission Controllers live inside the API Server, which is part of the Control Plane.

❌ They are not part of the Controller Manager (which runs controllers like ReplicaSet, Deployment, Node Controller).
✅ They act before etcd persistence, directly in the request flow.

🔎 Examples of Built-in Admission Controllers

NamespaceLifecycle – Prevents deleting default namespaces.
LimitRanger – Enforces default resource requests/limits.
ServiceAccount – Auto-assigns service accounts to pods.
NodeRestriction – Limits kubelet modifications to its own node/pods.

🆚 Admission Controllers vs ReplicaSet Controller

Admission Controllers – Intercept API requests (policy/security/mutation).
ReplicaSet Controller – Runs in Controller Manager, ensures Pod replicas match desired state.

They are both control plane features but serve very different roles.

📊 Other Plugin Points in Kubernetes

Apart from Admission Controllers, Kubernetes has other extensibility points:

Scheduler plugins – Influence pod placement.
CNI plugins – Provide networking.
CSI plugins – Provide storage.
CRI plugins – Run containers via runtimes.

Together, they make Kubernetes flexible and modular.

🎯 Final Thoughts

Admission Controllers and Webhooks are critical to production-grade Kubernetes. They:

Enforce security and compliance.
Standardize policy across clusters.
Enable advanced use cases like sidecar injection, custom validations, and governance.

In interviews, remember this golden line:
👉 “Admission Controllers are API Server plug-ins that mutate or validate requests before persistence, while Webhooks extend this capability with external logic.”