Cybersecurity glossary
What is a Kubernetes Admission Controller?
Learn what Kubernetes admission controllers do, how mutating and validating webhooks gate the API server, and how to enforce image, identity, and pod-security policy at deploy time.
Definition
A Kubernetes admission controller is a plugin or webhook that intercepts API requests after authentication and authorization but before object persistence, allowing the cluster to mutate, validate, or reject resources according to policy.
Why admission controllers matter
Kubernetes RBAC can let a developer create Pods and still leave the cluster wide open if those Pods may be privileged, pull from anywhere, or skip resource limits. Admission controllers are the policy layer that inspects the object itself.
They are the difference between “anyone in this namespace can deploy” and “anyone in this namespace can deploy only signed, non-root, resource-capped workloads from our registry.”
Where admission sits in an API request
Authentication
The API server identifies the user, service account, or impersonated identity.
RBAC authorization
Roles and bindings decide whether the verb on this resource is allowed at all.
Mutating admission
Webhooks and plugins may inject sidecars, default labels, or securityContext fields.
Object schema validation
Kubernetes checks the mutated object still matches the API schema.
Validating admission
Policies allow or deny. Failures return an error to kubectl or the controller.
Persist and later audit
The object is stored. Audit logs should record both the decision and the webhook that made it.
Common admission jobs in production clusters
Pod hardening
Reject privileged, hostPath, and hostNetwork; require non-root and dropped capabilities.
Image provenance
Allow only signed digests from approved registries; block :latest and public unknowns.
Resource and quota defaults
Inject CPU and memory requests so one noisy pod cannot starve a node.
Label and tenant policy
Require cost, owner, and sensitivity labels before a namespace can run workloads.
Built-in plugins versus external policy
| Mechanism | Best for | Watch out for |
|---|---|---|
| Built-in plugins | Pod Security, quotas, LimitRanger, NodeRestriction | Limited custom logic; must be enabled on the API server |
| ValidatingAdmissionPolicy (CEL) | In-process custom rules without a webhook fleet | CEL expressiveness and cluster version requirements |
| Mutating webhook | Sidecar injection and defaulting securityContext | Order, idempotency, and surprise diffs in GitOps |
| Validating webhook (OPA/Kyverno) | Org-wide custom policy packs | Availability, timeout, and fail-open mistakes |
Admission controller operations checklist
- Treat security webhooks as fail-closed and run them with multiple replicas and pod disruption budgets.
- Enable Pod Security admission at the strictest level each namespace can actually run.
- Restrict which identities can create or update MutatingWebhookConfiguration and ValidatingWebhookConfiguration.
- Pin webhook TLS to trusted CA bundles; never skip certificate verification.
- Log denials with the policy name so developers can fix the spec, not guess.
- Keep mutation deterministic so GitOps does not fight injected fields on every reconcile.
- Test policies in warn or audit mode before enforce, then remove the warn loophole.
- Do not rely on admission alone: combine with RBAC, network policy, and node hardening.
The practical takeaway
A Kubernetes admission controller intercepts objects after RBAC and before they are stored. Mutation can set safe defaults; validation can refuse privileged, unsigned, or unlabeled workloads.
Operate admission like production infrastructure: fail closed for security rules, keep webhooks available, and remember it only sees the declared spec—not what the process does after it starts.
Related security terms
Kubernetes RBAC
Decides who may attempt an API call; admission decides whether the object is acceptable.
Pod Security
A built-in admission plugin that enforces pod hardening levels.
Container Image Scanning
Scan results are often enforced by admission before a pod can schedule.
Image Registry
Admission commonly restricts which registries and digests may run.
Kubernetes Network Policy
Network rules complement admission: one gates specs, the other gates traffic.
Frequently asked questions
What is a Kubernetes admission controller in simple terms?
It is a checkpoint in the API server. After Kubernetes accepts who you are and that you are allowed to create a Pod, admission still inspects the Pod spec and can change it or refuse it.
What is the difference between mutating and validating admission?
Mutating webhooks can rewrite the object (inject sidecars, add labels, set runAsNonRoot). Validating webhooks only allow or deny. Mutation runs first so validation sees the final spec.
How is admission different from RBAC?
RBAC answers “may this identity call this verb on this resource?” Admission answers “is this object shape allowed in this cluster?” A permitted user can still be rejected for a privileged pod.
What happens if a webhook is down?
The failure policy decides. Fail closed (Fail) blocks matching requests; fail open (Ignore) lets them through. Security-critical webhooks should fail closed and be highly available.
Are built-in admission plugins the same as webhooks?
Built-in plugins (PodSecurity, LimitRanger, ResourceQuota, NodeRestriction) run in-process. Webhooks and ValidatingAdmissionPolicy call out or use CEL for custom rules.
Can admission replace runtime security?
No. Admission sees the declared spec. A process that later escapes, or a container that installs packages at start, is outside that snapshot.
Should every policy be an admission webhook?
Prefer built-in Pod Security, ValidatingAdmissionPolicy, and a small number of well-operated webhooks. Each extra webhook adds latency and a new outage mode.
References
Explore authoritative guidance and frameworks related to kubernetes admission controller.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.