Home / Knowledge hub / Admission controller
Knowledge hub
Admission controller
A cluster gate that can reject workloads breaking your security rules.
What it means
In Kubernetes, every request to create or change something goes through the API server. An admission controller is a step in that path that runs after the request is authenticated and authorised, and before the object is saved. It can approve the request, change it, or reject it.
That makes it a gate on what may run in your cluster. A rule such as no privileged containers, or images only from our registry, can be enforced there, not just written in a document. It is policy that runs, not policy that sits in a folder.
Why it matters
Without a gate, anyone with permission to deploy can start almost anything, including a container with full access to the host. Reviewing each deployment by hand does not scale, and mistakes get through in a hurry. An admission controller checks every request the same way, every time.
It turns written policy into a control. That matters for audits and for stopping common mistakes before they reach production, such as images with no signature or workloads that skip pod security standards. It builds on Kubernetes RBAC, which decides who may ask.
How it shows up
Kubernetes ships built-in admission controllers, including Pod Security Admission, and supports validating and mutating webhooks, so tools such as policy engines can plug in their own rules. Typical rules cover privileged mode, host paths, image sources, required labels and resource limits.
Know the gaps. A webhook set to fail open lets everything through when it is down. Some namespaces are often excluded from rules and then become the way round. Admission checks only new and changed objects, so existing workloads need a separate scan. Test by trying to deploy something that should be refused.
Questions people ask
Admission controller, answered
Is an admission controller the same as RBAC?
No. RBAC decides who may make a request. An admission controller decides whether the content of the request is acceptable. A person allowed to create pods can still be stopped from creating a privileged one.
They work together.
What is the difference between validating and mutating?
A mutating controller can change the object, such as adding a default setting or a label. A validating one can only accept or reject it. Mutation runs first, then validation.
Both are used for policy.
What does failure policy mean?
It decides what happens when a webhook cannot be reached. Set to ignore, requests pass without the check. Set to fail, they are refused until the webhook returns.
Choose it deliberately.
Do we need a policy engine?
Not at first. Built-in Pod Security Admission covers common baselines. Policy engines add custom rules, such as requiring signed images.
Add one when the built-in set no longer fits.
Does it protect running workloads?
Not directly. It acts when objects are created or changed. A workload that was admitted before the rule existed keeps running, so scan the cluster as well.
Combine it with runtime checks.
Sources
Where this comes from
Related
Terms that sit next to this one
Kubernetes RBAC
Rules for which accounts and services may do what inside a Kubernetes cluster.
Pod security standards
Built-in Kubernetes levels that restrict risky settings in pods.
Kubernetes
A system that runs and manages containers across many machines.
Privileged container
A container given near-host powers, so a flaw inside it is a flaw in the host.
Policy as code
Writing access rules as versioned, testable code instead of settings clicked by hand.
What can still be deployed?
Admission rules guard the cluster; we test the application inside it and report what we exploited, with the request and response. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.