3.12 Kubernetes Admission Chain

Kubernetes Admission Chain is the specific ordered list of individual admission plugins that an already-authorized request passes through, describing how the chain is split into a mutating phase followed by a validating phase, and how a request can be transformed multiple times before it is ever finally accepted or rejected.

Two Phases, Strictly Ordered

Every Mutating Plugin Runs Before Any Validating Plugin

The admission chain is architected around a strict two-phase order: every enabled mutating plugin runs first, in sequence, each potentially altering the request, and only once all mutating plugins have run does the chain move on to validating plugins, which evaluate the final, fully mutated object.

Why the Order Cannot Be Reversed

This ordering exists because validating plugins are meant to make an accept-or-reject decision based on the object's actual final content; if validation ran before mutation, it would be evaluating a version of the object that might still change afterward, making its decision potentially meaningless.

Within the Mutating Phase

Sequential Application, Each Building on the Last

Multiple mutating plugins can be chained together, each one receiving the object as modified by the previous plugin in the sequence, meaning the final mutated object is the cumulative result of every plugin's changes applied in order, not just the result of any single one.

Built-In and Webhook-Based Plugins Interleaved

The mutating phase of the chain can include both plugins compiled directly into the API server and external mutating webhooks, interleaved according to configured ordering, meaning a built-in default-setting plugin and an external policy-injection webhook can both participate in shaping the same request.

Within the Validating Phase

Every Validator Must Agree

Unlike authorization's any-allow resolution, the validating phase of the admission chain requires every validating plugin to accept the request; if any single validator rejects it, the request fails admission entirely, regardless of how many other validators would have approved it.

No Further Mutation Possible

Once the chain enters the validating phase, no further changes to the object are architected to occur; validating plugins are structurally limited to inspection and accept-or-reject decisions, never modification.

Chain Termination

First Rejection Ends the Chain

If any plugin at either phase rejects the request, the admission chain terminates immediately at that point, and the request is denied without continuing through any remaining plugins in the chain.

Successful Completion Reaches Persistence

Only a request that passes every plugin in both phases, without rejection, continues on to be persisted in etcd, completing its journey through the admission chain.

Admission Chain Diagram