Kubernetes Admission Control

Admission controllers are the last line of defense in the Kubernetes API request pipeline. They run after authentication and authorization but before the object is written to etcd. Mutating controllers can modify objects; validating controllers can accept or reject them. Understanding the admission chain is critical for implementing security policies and for debugging mysterious resource creation failures.

Overview

Overview

Admission control is the mechanism that makes Kubernetes policy enforcement possible. Without admission controllers, any authenticated user with RBAC permission to create pods could create pods that run as root, mount host paths or bypass resource limits.

> [!IMPORTANT] Admission is the second policy layer that turns Kubernetes from a simple container scheduler into a multi-tenant platform with enforceable governance.

Admission is a pipeline, not a single check

A request that reaches admission is already authenticated and authorized. Admission is the third layer, asking whether this specific object is acceptable given the cluster's policies.

  • Authentication — Is the user who they say they are?
  • Authorization — Do they have permission to create this resource type?
  • Admission — Is this specific object acceptable under cluster policy?

Mutating webhooks: the injection pattern

MutatingAdmissionWebhooks power the sidecar injection of service meshes like Istio, Linkerd and Cilium. The mesh injects containers transparently at create time instead of users adding them by hand.

> [!TIP] This mechanism explains why pods have unexpected containers, or fail to start with init container errors.

ValidatingAdmissionPolicy: CEL in the API server

ValidatingAdmissionPolicy (CEL-based, GA in 1.30) is the direction Kubernetes is heading for in-cluster policy. Policies are Kubernetes objects evaluated natively by the API server, with no separate webhook server to run.

  • Gatekeeper or Kyverno webhook — Separate policy webhook server — Deploy and manage it
  • ValidatingAdmissionPolicy (CEL) — Inside the API server — Zero

> [!NOTE] Teams using Gatekeeper or Kyverno only for simple label or annotation checks or security context enforcement can replace them with CEL policies.

Key concepts

Webhook failurePolicy and Selector Scoping
The failurePolicy field in a webhook configuration determines what happens when the webhook endpoint is unreachable or returns an error. Fail (the default) causes the API request to be rejected. Ignore causes the webhook to be skipped and the request to proceed. The choice of failurePolicy is a security/availability tradeoff. For security-critical webhooks (deny-all-privileged), use Fail — you want to block resource creation when the policy engine is down rather than allow potentially unsafe resources. For convenience webhooks (label defaulting), use Ignore — a transient webhook outage should not block pod creation. Namespace selectors are equally critical. Always exclude kube-system from validating webhooks, because if the webhook itself fails to start (it lives in kube-system), and its failurePolicy is Fail, new pods cannot be created in kube-system to fix the webhook — a deadlock. Also set timeoutSeconds: 5 (maximum recommended). The default is 10 seconds, and a slow webhook on every pod creation will make your cluster feel sluggish.

When to use it

  • When implementing a security baseline for a production cluster and deciding between PSA, OPA/Gatekeeper, Kyverno, and ValidatingAdmissionPolicy
  • When debugging resource creation failures that return webhook rejection errors without obvious reasons
  • When a service mesh is not working as expected and you need to understand why sidecar injection is or is not happening
  • When preparing for CKA or CKAD exam topics on security contexts and pod security standards
  • When writing a custom admission webhook and need to understand the request/response contract and failure modes

Sign up free to read the full topic

More DevOps topics

Start free on Cariara · Coding problems · System design studio