24 Kubernetes Admission and Policy

Kubernetes Admission and Policy is the stage of API request processing that occurs after authentication and authorization have already approved a request, during which additional validation and mutation logic is applied before the change is persisted, allowing cluster-wide rules and conventions to be enforced consistently regardless of who submitted the request.

Where Admission Fits

After Authorization, Before Persistence

By the time a request reaches admission control, Kubernetes has already confirmed the requester's identity and that they are permitted to perform the requested action. Admission control adds a further layer of scrutiny focused not on who is making the request, but on whether the request itself conforms to cluster policy.

Two Categories of Plugins

Admission plugins fall into two categories: mutating plugins, which can modify a request before it is persisted, and validating plugins, which can only accept or reject a request without altering it. Mutating plugins always run before validating plugins, ensuring that validation checks see the final, fully mutated version of an object.

Built-In Admission Controllers

Common Examples

Kubernetes ships with a number of built-in admission controllers, such as ones that enforce resource limits from a namespace's LimitRange, others that automatically inject a default service account into Pods that do not specify one, and others that reject requests referencing namespaces that do not exist.

Enabling and Ordering

Which admission controllers are active is configured at the API server level, and because plugins run in a defined order, the behavior of one plugin can depend on mutations already applied by an earlier one in the chain.

Dynamic Admission Webhooks

Extending Admission Without Rebuilding the API Server

MutatingAdmissionWebhook and ValidatingAdmissionWebhook allow cluster operators to register external services that the API server calls out to during admission, enabling custom policy logic without modifying or rebuilding the API server itself.

Common Use Cases

Webhooks are commonly used to enforce organizational conventions, such as requiring specific labels on all Pods, automatically injecting sidecar containers such as service mesh proxies, or blocking Pods that request privileged access without explicit justification.

Policy-as-Code Frameworks

Declarative Policy Definition

Rather than writing custom webhook services from scratch, many clusters adopt policy engines that allow rules to be expressed declaratively, evaluated automatically against incoming requests through the same webhook mechanism, and managed as version-controlled policy definitions alongside other cluster configuration.

Enforcement vs. Audit Modes

Policy engines typically support both an enforcement mode, which rejects non-compliant requests outright, and an audit mode, which logs violations without blocking them, allowing new policies to be evaluated safely before being made mandatory.

Why Admission and Policy Matter

Consistency at Scale

As the number of teams and applications sharing a cluster grows, relying on manual review to catch policy violations does not scale. Admission control and automated policy enforcement provide a consistent, automatic checkpoint that applies the same rules to every request, regardless of who submits it or through which tool.

Admission Pipeline Diagram