Kubernetes Admission Controller.

Kubernetes admission sits in the API-server request pipeline after authentication and authorization but before the object is written to etcd. It runs in two ordered phases: mutating controllers can rewrite the object (set defaults, inject an Istio/Envoy sidecar), then validating controllers accept or reject it. Built-in controllers include NamespaceLifecycle, ResourceQuota, ServiceAccount, PodSecurity, and ImagePolicyWebhook. External policy engines register as MutatingWebhookConfiguration/ValidatingWebhookConfiguration, receive an AdmissionReview JSON payload, and return an allow/deny verdict — this is where OPA Gatekeeper and Kyverno plug in. Since 1.30 (GA), ValidatingAdmissionPolicy embeds CEL expressions directly in the API server, removing the webhook network hop.

Admission is the primary enforcement point for supply-chain and workload policy: image-signature verification (Sigstore/cosign), Pod Security Standards, and label hygiene. That makes the webhook itself a target. The March 2025 IngressNightmare cluster (CVE-2025-1974, CVSS 9.8, with CVE-2025-1097/1098/24514) let an unauthenticated attacker reach the ingress-nginx admission endpoint and inject NGINX directives, achieving RCE in the controller pod and potential cluster-wide secret theft — a stark reminder that admission endpoints must never be network-exposed.

Operationally, failurePolicy: Fail with an unreachable webhook can brick the cluster, so scope webhooks with namespaceSelector, set tight timeoutSeconds, and exclude kube-system.

flowchart LR
  U[kubectl / client] --> API[API server]
  API --> AUTHN[Authentication]
  AUTHN --> AUTHZ[Authorization RBAC]
  AUTHZ --> MUT[Mutating admission -> inject / default]
  MUT --> SCH[Schema & object validation]
  SCH --> VAL[Validating admission + VAP CEL]
  VAL --> D{Allowed?}
  D -->|Reject| ERR[Request denied to client]
  D -->|Allow| ETCD[(Persist to etcd)]
  VAL -.policy.-> ENG[OPA Gatekeeper / Kyverno]