Admission Controllers and Webhooks

A request reaches the Kubernetes API server. Authentication passes. Authorization passes. The object still gets rejected. What's rejecting it? Admission control.

The admission layer sits between authorization and etcd. Every create, update, or delete goes through it twice: mutating webhooks first, validating webhooks second. You can insert your own logic at either point, but the configuration details (failurePolicy, namespaceSelector, sideEffects) determine whether that logic hardens your cluster or becomes its single point of failure. Built-in controllers handle the invariants: defaulting service accounts, enforcing quotas, protecting PVCs. Dynamic webhooks are where you take over.