Kubernetes Admission Chain

Kubernetes Admission Chain validates and modifies resources before persistence, ensuring cluster compliance and security.

Kubernetes Admission Chain is the specific, ordered list of individual admission controllers, built-in and webhook-based, that a request passes through during the mutating and validating admission stages, tracing exactly which controllers run, in what order, and how built-in controllers and registered webhooks interleave within the same overall chain rather than being separate mechanisms.

Structure of the Chain

Two Sub-Chains: Mutating, Then Validating

The admission chain is formally split into two ordered sub-chains executed sequentially: every enabled mutating admission controller runs first, in the order the API server was configured with, followed by every enabled validating admission controller, also in configured order, with no validating controller seeing the object until every mutating controller has finished modifying it.

object \to {mutate}_{1} \to {mutate}_{2} \to \dots \to {validate}_{1} \to {validate}_{2} \to \dots

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota

Representative Built-in Controllers in the Chain

NamespaceLifecycle

Formally rejects requests to create new objects in a namespace that is terminating, and prevents deletion of certain reserved namespaces, enforcing the boundary of a namespace's own lifecycle before any object-specific logic runs.

LimitRanger

Formally applies the default, minimum, and maximum resource values defined by any applicable LimitRange in the request's namespace, mutating an object lacking explicit resource requests or limits before validation of those values against namespace policy occurs.

ServiceAccount

Formally ensures a Pod references a valid ServiceAccount, defaulting to the namespace's default ServiceAccount if none is specified, and attaches the appropriate token volume, mutating the Pod before it is persisted.

ResourceQuota

Formally runs late in the validating sub-chain, since it must observe the final, fully mutated and defaulted object to accurately account for its resource consumption against the namespace's ResourceQuota, rejecting the request if it would exceed the quota's hard limits.

kubectl describe resourcequota codartium-team-quota -n codartium-team

ResourceQuota position = late validating (after mutation and defaulting)

PodSecurity

Formally evaluates a Pod against the Pod Security Standard level configured for its namespace (privileged, baseline, or restricted), rejecting or warning on violations as a validating step, distinct from and layered atop any container-level securityContext the workload itself declares.

Where Webhooks Fit Within the Chain

Registered Webhooks Run Alongside Built-in Controllers

A MutatingWebhookConfiguration formally inserts an external webhook call into the mutating sub-chain, and a ValidatingWebhookConfiguration inserts one into the validating sub-chain, each treated by the chain as an ordinary participant, distinguished from built-in controllers only by being invoked over the network rather than in-process.

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: codartium-defaulter
webhooks:
  - name: default-resources.codartium.io
    rules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]

Multiple Webhooks and Their Relative Order

Where multiple mutating webhooks are registered for the same request, they are formally invoked in an order determined by the API server (commonly lexicographic by configuration name unless otherwise specified), with each webhook seeing the cumulative result of every mutation applied before it, meaning webhook authors cannot generally assume their webhook is the first or only one to see the object.

Schema Validation as the Boundary Between Sub-Chains

Structural Validation After Mutation

Between the mutating and validating sub-chains, the API server formally validates the mutated object's structure against its OpenAPI schema; a mutating webhook that produces a structurally invalid object formally causes the request to fail at this boundary, before any validating controller or webhook is even consulted.

mutating chain \to schema validation \to validating chain

Chain-Wide Failure Behavior

One Rejection Halts the Entire Chain

Any single controller or webhook within either sub-chain formally rejecting the request halts the entire admission chain immediately; no subsequent controller in either sub-chain is consulted once a rejection occurs, and the request fails with that specific controller's stated reason.

kubectl apply -f pod.yaml
# error: admission webhook "trusted-registry.codartium.io" denied the request: image must come from an approved registry

Why the Chain Is Ordered and Composable This Way

Structuring admission as an ordered chain of narrowly scoped, independently pluggable controllers, built-in or webhook, mutating before validating, is what formally allows defaulting and normalization (mutation) to complete fully before any policy check (validation) is evaluated, ensuring that validating logic, including ResourceQuota's resource accounting, always operates against the final, fully resolved object rather than an incomplete, pre-default version of it.