Kubernetes Admission Definition

Kubernetes Admission Definition explains how Kubernetes enforces policies through admission controllers, ensuring compliance and security in containerized environments.

Kubernetes Admission Definition is the precise characterization of admission control as the final formal stage of API request processing, positioned strictly after authentication and authorization have already approved a request and strictly before that request's object is persisted to etcd, during which the request may still be mutated or rejected based on rules evaluating the object's content rather than merely the requester's identity and intended verb.

Formal Position in the Request Pipeline

Ordering Guarantee

The API server formally processes every write request through a fixed sequence: authentication, then authorization, then mutating admission, then schema validation, then validating admission, and only then persistence. Admission control, by definition, never runs before authorization has already succeeded, and never runs after the object has already been written.

authn \to authz \to mutating admission \to schema validation \to validating admission \to persist

Content-Based, Not Identity-Based

Admission control is formally distinguished from authorization by what it evaluates: authorization asks whether a given identity may perform a given verb on a given resource type in the abstract; admission asks whether this specific object's content, its labels, its resource requests, its image reference, its security settings, satisfies additional constraints, independent of who submitted it.

Formal Categories of Admission Controllers

Mutating Admission

A mutating admission controller is formally permitted to modify the incoming object before it proceeds further in the pipeline, such as injecting default values, adding labels, or inserting a sidecar container, and every mutating controller configured to match a given request runs before any validating controller sees the (possibly now-modified) object.

Validating Admission

A validating admission controller is formally restricted to accepting or rejecting a request; it may not alter the object's content, only allow or deny the request as submitted (after any prior mutation), optionally attaching a human-readable reason for a rejection.

mutating: object → object′, validating: object′ → {accept, reject}

Built-in vs. Dynamic Admission

Built-in Admission Controllers

Built-in admission controllers are formally compiled into the API server binary itself, enabled or disabled through server startup configuration, and cover foundational concerns such as ResourceQuota enforcement, LimitRanger default application, and NamespaceLifecycle protection of terminating namespaces.

Dynamic Admission via Webhooks

A MutatingWebhookConfiguration or ValidatingWebhookConfiguration formally registers an external HTTP service to participate in the admission pipeline for matching requests, without requiring any change to the API server's own code, extending the admission mechanism arbitrarily beyond what is built in.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: codartium-policy-check
webhooks:
  - name: require-limits.codartium.io
    rules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
    clientConfig:
      service:
        name: policy-webhook
        namespace: codartium-security
        path: /validate
    admissionReviewVersions: ["v1"]
    sideEffects: None
    failurePolicy: Fail

Formal Contract of a Webhook Call

AdmissionReview Exchange

The API server formally sends a webhook an AdmissionReview object containing the request's full details, including the object being created or modified, and expects an AdmissionReview response indicating whether the request is allowed, and, for mutating webhooks, an optional JSON patch describing the requested modification.

{
  "response": {
    "uid": "abc-123",
    "allowed": false,
    "status": { "message": "CPU and memory limits are required." }
  }
}

failurePolicy

failurePolicy formally determines the outcome when a webhook cannot be reached or times out: Fail treats the request as rejected, prioritizing strict enforcement; Ignore treats the request as though the webhook were absent, prioritizing continued cluster operation over strict policy enforcement.

In-Process Alternative: ValidatingAdmissionPolicy

CEL-Based Evaluation Without a Webhook

ValidatingAdmissionPolicy formally allows validation rules to be expressed using the Common Expression Language and evaluated directly within the API server process, avoiding the network round-trip and availability dependency inherent to a webhook-based validating controller for the rules it covers.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-non-root
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
  validations:
    - expression: "object.spec.securityContext.runAsNonRoot == true"

kubectl get validatingwebhookconfigurations
kubectl get mutatingwebhookconfigurations
kubectl get validatingadmissionpolicies

Why Admission Is a Formally Distinct Stage

Placing admission strictly between authorization and persistence, and formally subdividing it into a mutating phase followed by a validating phase, is what allows policy that depends on an object's specific content, rather than merely the requester's identity, to be enforced consistently and automatically for every write, without requiring that logic to be duplicated across every client capable of submitting objects to the cluster.