Admission Controllers: KCA practice questions

Kyverno runs as a dynamic admission controller, so this topic is about where policy decisions sit in the Kubernetes API request flow. An admission controller intercepts requests to the API server after the request is authenticated and authorized and before the object is persisted. Admission runs in two phases: mutating controllers first, which may change the object, and validating controllers second, which may not. If any controller in either phase rejects the request, the whole request is rejected and the user receives an error. Admission applies to requests that create, update or delete objects and to some custom verbs such as connecting to a pod through the API server proxy; it does not and cannot block reads, so get, list and watch bypass it.

Dynamic admission control adds external webhooks to those phases. Mutating admission webhooks are called first and can set custom defaults. After all modifications are complete and the API server has validated the object, validating admission webhooks are called and can reject it. Kubernetes advises that a webhook that must see the final state of an object should be a validating one, because objects can still change after a mutating webhook has seen them. Kyverno's guide adds that mutating webhooks are called one after another in lexical order of their configuration names, each seeing the previous changes, while validating webhooks are called in parallel.

Each webhook has a failurePolicy and a timeout. Ignore lets the request continue when calling the webhook fails; Fail, the default, rejects it. The timeout defaults to 10 seconds and must be between 1 and 30, and when it expires the failure policy decides. A namespaceSelector can limit which namespaced requests reach a webhook based on namespace labels.

Kyverno receives both mutating and validating webhook callbacks. Its webhook server handles the AdmissionReview requests and passes them to the policy engine, and its webhook controller watches installed policies and adjusts the webhook configurations so the API server only sends the resources those policies match. A background controller handles generate and mutate-existing rules through intermediate UpdateRequest resources, report controllers build policy reports, and a certificate renewer maintains the webhook's certificates, stored in Secrets. Image verification rules run after other mutation rules and before the validation webhook. Kyverno's default webhook namespaceSelector excludes the kube-system and kyverno namespaces.

The difference between a webhook and a policy is a useful mental model from the Kyverno guide: a webhook is an instruction for the API server, telling it what to send where and how long to wait, while a policy is an instruction for the controller that answers. Admission only ever sees new and changed objects, which is why Kyverno complements it with background scans of existing resources; those scans report violations but never block anything. Kubernetes also offers ValidatingAdmissionPolicy and MutatingAdmissionPolicy, which embed declarative validation or mutation inside the API server without an HTTP callout.