Kubernetes Admission Controllers: The Gatekeepers You Didn't Know You Needed

When we talk about Kubernetes security and governance, most discussions revolve around RBAC, Network Policies, or Pod Security. But there’s a lesser-known yet powerful layer that silently governs every object entering your cluster: Admission Controllers. Let’s dive into what they are, how they work, and why they deserve your attention—especially if you're aiming for production-grade cluster security and consistency. What Are Admission Controllers? Admission Controllers are plugins that intercept API requests to the Kubernetes API server after authentication and authorization, but before the request is persisted to etcd. They can validate, mutate, or even deny resource creation and updates based on custom logic or policy. There are two main types: Mutating Admission Controllers: Modify incoming requests (e.g., inject labels or sidecars). Validating Admission Controllers: Enforce policies by allowing or rejecting requests. The Flow of a Request Here’s what happens when you make a request like kubectl create -f pod.yaml: Authentication – Who are you? Authorization – Are you allowed to do this? Admission Control – Should this request be allowed? Should it be changed? etcd – If all checks pass, the object is stored. Built-In Admission Controllers Kubernetes ships with many built-in admission plugins. Some of the most useful ones: NamespaceLifecycle: Prevents deletion of system namespaces. LimitRanger: Enforces resource limits (CPU/memory). PodSecurity: Enforces security contexts (replaces the old PodSecurityPolicy). NodeRestriction: Prevents nodes from modifying critical objects. TaintNodesByCondition: Automatically taints nodes based on their condition. You can see which controllers are enabled by checking your API server’s --enable-admission-plugins flag. Dynamic Admission Controllers (Webhooks) Static admission plugins are useful, but not flexible enough for most production use cases. For more dynamic control, Kubernetes offers: MutatingAdmissionWebhook ValidatingAdmissionWebhook These let you define external HTTP callbacks that run your custom logic against every resource creation/update. Use cases include: Automatically adding labels to every resource. Enforcing naming conventions. Preventing deployments without resource requests. Blocking updates to protected ConfigMaps. Writing Your Own Admission Webhook If you want full control, you can write a webhook server that handles admission requests. Here’s a high-level view: Write a small server in Go (or another language) that implements the admission logic. Deploy it inside the cluster. Create a MutatingWebhookConfiguration or ValidatingWebhookConfiguration resource. Kubernetes will call your service for every relevant API request. It's a powerful way to centralize and enforce policies. Final Thoughts Admission Controllers are the last line of defense before anything touches etcd. They offer deep control over the security, compliance, and consistency of your cluster. If you're managing multi-tenant environments, production workloads, or regulated systems, Admission Controllers aren't optional—they're your secret weapon. Next up: Want a walkthrough on writing a custom Validating Webhook in Go or how to test Admission Webhooks locally? Let me know in the comments!

Apr 5, 2025 - 15:52

Kubernetes Admission Controllers: The Gatekeepers You Didn't Know You Needed

When we talk about Kubernetes security and governance, most discussions revolve around RBAC, Network Policies, or Pod Security. But there’s a lesser-known yet powerful layer that silently governs every object entering your cluster: Admission Controllers.

Let’s dive into what they are, how they work, and why they deserve your attention—especially if you're aiming for production-grade cluster security and consistency.

What Are Admission Controllers?

Admission Controllers are plugins that intercept API requests to the Kubernetes API server after authentication and authorization, but before the request is persisted to etcd.

They can validate, mutate, or even deny resource creation and updates based on custom logic or policy.

There are two main types:

Mutating Admission Controllers: Modify incoming requests (e.g., inject labels or sidecars).
Validating Admission Controllers: Enforce policies by allowing or rejecting requests.

The Flow of a Request

Here’s what happens when you make a request like kubectl create -f pod.yaml:

Authentication – Who are you?
Authorization – Are you allowed to do this?
Admission Control – Should this request be allowed? Should it be changed?
etcd – If all checks pass, the object is stored.

Built-In Admission Controllers

Kubernetes ships with many built-in admission plugins. Some of the most useful ones:

NamespaceLifecycle: Prevents deletion of system namespaces.
LimitRanger: Enforces resource limits (CPU/memory).
PodSecurity: Enforces security contexts (replaces the old PodSecurityPolicy).
NodeRestriction: Prevents nodes from modifying critical objects.
TaintNodesByCondition: Automatically taints nodes based on their condition.

You can see which controllers are enabled by checking your API server’s --enable-admission-plugins flag.

Dynamic Admission Controllers (Webhooks)

Static admission plugins are useful, but not flexible enough for most production use cases.

For more dynamic control, Kubernetes offers:

MutatingAdmissionWebhook
ValidatingAdmissionWebhook

These let you define external HTTP callbacks that run your custom logic against every resource creation/update.

Use cases include:

Automatically adding labels to every resource.
Enforcing naming conventions.
Preventing deployments without resource requests.
Blocking updates to protected ConfigMaps.

Writing Your Own Admission Webhook

If you want full control, you can write a webhook server that handles admission requests. Here’s a high-level view:

Write a small server in Go (or another language) that implements the admission logic.
Deploy it inside the cluster.
Create a MutatingWebhookConfiguration or ValidatingWebhookConfiguration resource.
Kubernetes will call your service for every relevant API request.

It's a powerful way to centralize and enforce policies.

Final Thoughts

Admission Controllers are the last line of defense before anything touches etcd. They offer deep control over the security, compliance, and consistency of your cluster.

If you're managing multi-tenant environments, production workloads, or regulated systems, Admission Controllers aren't optional—they're your secret weapon.

Next up: Want a walkthrough on writing a custom Validating Webhook in Go or how to test Admission Webhooks locally? Let me know in the comments!