1.23 Kubernetes Admission Definition

Kubernetes Admission Definition is the precise characterization of admission control as the request-processing stage that occurs strictly after authentication and authorization have both already approved a request, defined by its position as the final gate through which a request must pass before the API server persists it, and by its division into mutating and validating phases that always run in that fixed order.

Position in the Request Pipeline as Part of the Definition

Strictly After Authorization

Admission control is defined by where it sits in the request pipeline: it only ever processes requests that have already been authenticated and authorized, meaning a request denied by authorization never reaches admission at all, and admission logic can assume the requester was already permitted to attempt the action.

Before Persistence, Not After

Equally defining is that admission occurs before a request is written to the cluster's data store; anything admission rejects or fails to approve never becomes durable cluster state, distinguishing admission from mechanisms that react to changes only after they have already taken effect.

Mutating and Validating as Defined Phases

Mutation Always Precedes Validation

Admission is defined around two distinct phases that run in a fixed order: mutating admission, which may alter the incoming request, runs first, and validating admission, which may only accept or reject, runs second, ensuring that validation always evaluates the final, fully mutated version of an object.

Validating Plugins Cannot Modify

A validating admission plugin is defined strictly by the inability to change the request it inspects; it is limited to a binary accept-or-reject decision, a constraint that distinguishes it structurally from mutating plugins even when the two are implemented using the same underlying webhook mechanism.

Built-In vs. Dynamic Admission as a Defining Distinction

Compiled-In Plugins

Built-in admission plugins are defined as logic compiled directly into the API server, enabled or disabled through server configuration, and limited to whatever behaviors the Kubernetes codebase itself implements.

Webhook-Based Extension

Dynamic admission, through MutatingWebhookConfiguration and ValidatingWebhookConfiguration objects, is defined as a mechanism for registering external services the API server calls out to during the admission phase, extending admission behavior without requiring changes to the API server's own code.

What Falls Outside the Admission Definition

Not a Substitute for Authorization

Admission control is defined to operate only after authorization has already granted permission for an action; it is not a mechanism for controlling who may attempt an action, only for further constraining or modifying the shape of actions that are already permitted.

Not Retroactive

Because admission occurs strictly before persistence, it is defined as having no bearing on objects that already exist in the cluster; changes to already-persisted objects are not retroactively subjected to newly added admission rules unless those objects are updated again.

Admission Phase Ordering Diagram