The Importance of Configuring Your Admission Controller Early in Kubernetes

Kubernetes admission controllers intercept API requests after authentication but before objects persist, letting you validate, mutate, or reject deployments based on your rules. Configure them early — before workloads land — because retrofitting policies onto a running cluster forces painful exceptions. The default kube-apiserver enables a sensible baseline (NodeRestriction, PodSecurity, ResourceQuota); add custom validating webhooks for org-specific rules.

Introduction

In a Kubernetes (k8s) environment, the admission controller plays a crucial role in filtering input to the cluster. To ensure optimal performance and security, it is vital to configure your admission controller before you start using the cluster. Failing to do so can lead to problems that could have been prevented by the admission controller. In this essay, we will discuss the basics of an admission controller, its benefits, potential challenges, and the importance of early configuration.

Understanding Admission Controllers

An admission controller is essentially a set of callback hooks for the Kubernetes API, specifically targeting object creation or mutation. It allows you to intercept requests to the Kubernetes API server before the persistence of the object, giving you the opportunity to validate, modify, or even reject the request.

Kubernetes comes with a basic admission controller out of the box, which can enforce resource limits presence, among other things. However, there are some specific behaviors to be aware of. For instance, when a check fails, the kubectl apply command will return a 0 exit code, but the pods will not be created. This can be problematic if your CI/CD pipeline does not verify the deployment outcome.

You may use one of many open-sourced controllers from Github, e.g. https://github.com/douglasmakey/admissioncontroller, as a starting point to write your own controller.

Benefits of Admission Controllers

• Saves manual review: By automating the validation and modification of objects, admission controllers can save time and effort that would otherwise be spent on manual review.

• Fixes potential problems: Admission controllers can identify and prevent issues before they escalate, ensuring that your cluster remains secure and efficient.

Challenges with Admission Controllers

• Configuration: To take full advantage of an admission controller, you need to configure it properly, which can be a complex task, especially for those new to Kubernetes.

• Writing custom controllers: Creating a custom admission controller requires writing Go code to perform the validation. This task typically demands the skills of a middle-grade Go programmer, which might not be readily available in all organizations.

• Documentation discrepancies: As of now, Kubernetes APIs are at version 1, but most documentation still refers to version 1beta. This discrepancy complicates the configuration process. While documentation updates are expected over time, finding accurate information can be challenging at the moment.

Default plugins worth enabling on day one

The kube-apiserver flag --enable-admission-plugins=NodeRestriction,PodSecurity,ResourceQuota,LimitRanger covers most baseline security and resource hygiene. NodeRestriction stops kubelets from modifying nodes other than their own. PodSecurity enforces pod security standards (replaces the deprecated PodSecurityPolicy). ResourceQuota and LimitRanger together prevent a single namespace from starving the cluster.

Conclusion

Configuring your admission controller early in the Kubernetes cluster setup process is essential to ensure optimal performance, security, and efficiency. While there are challenges associated with configuring and writing custom admission controllers, the benefits far outweigh the drawbacks. By investing time and resources in setting up your admission controller correctly from the start, you can save yourself from potential problems down the line and maintain a secure and efficient Kubernetes environment.

Need help hardening your Kubernetes cluster, designing admission policies, or running production workloads safely? Our Kubernetes consulting team has hardened clusters for healthcare, fintech, and SaaS customers — from baseline policy setup through full incident response.

Frequently Asked Questions

What is a Kubernetes admission controller?

An admission controller is a plugin that intercepts requests to the Kubernetes API server after authentication and authorization, but before the object is persisted to etcd. It can inspect, modify, or reject the request. Kubernetes ships with built-in controllers like NodeRestriction and PodSecurity, and lets you add custom validating or mutating webhooks for org-specific rules.

Why should I configure admission controllers before deploying workloads?

Once workloads are running, every new policy you add risks rejecting in-flight deployments and triggering rollback work. Setting baseline admission controllers (resource quotas, pod security, image registry whitelist) before any real workloads land means you start enforcing rules from day one and don't carry technical debt from non-compliant resources.

What is the difference between validating and mutating admission webhooks?

Validating webhooks inspect requests and return allow or deny — they cannot change the object. Mutating webhooks can rewrite the object before it reaches the API server (for example, injecting sidecar containers or default labels). Mutating webhooks run first, then validating webhooks. Use mutating sparingly because they make cluster behavior less predictable.

What's the simplest custom admission controller to start with?

A validating webhook that rejects pods missing required labels (like team, env, or cost-center) is the easiest first project. It enforces tagging discipline without altering objects, runs in a few lines of Go, and gives immediate operational value. The open source admissioncontroller starter is a solid template.

Will admission controllers slow down my cluster?

In-process admission plugins (the built-in ones) add microseconds and are essentially free. External webhooks add a network round-trip per request, which usually means 5-50ms extra latency on object creation. For most clusters this is invisible, but if you have a very high object churn rate or chain many webhooks, monitor the API server's apiserver_admission_webhook_admission_duration_seconds metric.

Related Reading

• How to choose the right Kubernetes distribution for your business
• How to write basic Admission Controller and how it works
• Kubernetes at Your Fingertips