Courses Kubernetes attack & defenseAdmission control internals

Admission control internals

The pipeline, webhook order, and enforcement.

Advanced35 min · lesson 7 of 15

Admission control is where the cluster decides whether a request that already passed authentication and authorization is actually allowed to become an object. It is the enforcement point for most of your security policy — and understanding its internals is what lets you use it correctly and spot its bypasses.

The request flow and webhook order

Every write to the API server passes through a pipeline: authentication, then authorization (RBAC), then admission, and only then is the object persisted to etcd. Admission itself has phases: mutating admission webhooks run first (injecting sidecars, defaulting fields), then the object is schema-validated, then validating admission webhooks run to accept or reject it. The ordering is deliberate — mutation happens before validation so the final, mutated object is what gets checked. Because admission runs before persistence, a rejecting webhook stops a bad object from ever existing.

the admission pipeline

#  request ─▶ authentication ─▶ authorization (RBAC) ─▶ ADMISSION ─▶ etcd
#                                                          │
#                          ┌───────────────────────────────┤
#                          ▼               ▼               ▼
#                   mutating webhooks  schema valid.  validating webhooks
#                   (inject/default)   (structure)    (accept / REJECT)
#
# A ValidatingWebhookConfiguration binds your policy service to this gate:
#   rules: [{ operations: [CREATE, UPDATE], resources: [pods] }]
#   failurePolicy: Fail        # secure default (see next lesson)

What admission enforces

This gate is how you enforce the security policy the rest of the course produces: reject privileged or hostPath pods, require that images are signed by your pipeline, mandate resource limits and non-root, inject a default seccomp profile. Kubernetes ships built-in admission plugins (including Pod Security Admission), and policy engines like Kyverno and OPA Gatekeeper add custom, cluster-specific rules. The admission layer is the difference between "we have a policy" and "the cluster enforces the policy" — but only if it cannot be bypassed, which is where the internals matter.

Admission is the last gate before etcd

Runs after RBAC, before persistence. Reject here and the bad object never exists — the enforcement point for pod security, signatures, and custom policy.

Authorization is not admission

RBAC decides whether a subject may perform an operation; admission decides whether the specific object is acceptable. A subject with create-pods permission is authorized to make pods — only admission control can stop them making a privileged one. Do not rely on RBAC alone to enforce workload security posture.

Privilege escalation pathsPSA, Kyverno & Gatekeeper