Admission Control in Kubernetes [page]deterministic

referencesecurity

This page provides an overview of _admission controllers_.

An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the resource, but after the request is authenticated and authorized.

Several important features of Kubernetes require an admission controller to be enabled in order to properly support the feature. As a result, a Kubernetes API server that is not properly configured with the right set of admission controllers is an incomplete server that will not support all the features you expect.

## What are they?

Admission controllers are code within the Kubernetes [API server](#gloss:kube-apiserver) that check the data arriving in a request to modify a resource.

Admission controllers apply to requests that create, delete, or modify objects. Admission controllers can also block custom verbs, such as a request to connect to a pod via an API server proxy. Admission controllers do _not_ (and cannot) block requests to read (get, watch or list) objects, because reads bypass the admission control layer.

Admission control mechanisms may be _validating_, _mutating_, or both. Mutating controllers may modify the data for the resource being modified; validating controllers may not.

The admission controllers in Kubernetes consist of the [list](#what-does-each-admission-controller-do) below, are compiled into the `kube-apiserver` binary, and may only be configured by the cluster administrator.

### Admission control extension points

Within the full [list](#what-does-each-admission-controller-do), there are three special controllers: [MutatingAdmissionWebhook](#mutatingadmissionwebhook), [ValidatingAdmissionWebhook](#validatingadmissionwebhook), and [ValidatingAdmissionPolicy](#validatingadmissionpolicy). The two webhook controllers execute the mutating and validating (respectively) [admission control webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) which are configured in the API. ValidatingAdmissionPolicy provides a way to embed declarative validation code within the API, without relying on any external HTTP callouts.

You can use these three admission controllers to customize cluster behavior at admission time.

### Admission control phases

The admission control process proceeds in two phases. In the first phase, mutating admission controllers are run. In the second phase, validating admission controllers are run. Note again that some of the controllers are both.

If any of the controllers in either phase reject the request, the entire request is rejected immediately and an error is returned to the end-user.

Finally, in addition to sometimes mutating the object in question, admission controllers may sometimes have side effects, that is, mutate related resources as part of request processing. Incrementing quota usage is the canonical example of why this is necessary. Any such side-effect needs a corresponding reclamation or reconciliation process, as a given admission controller does not know for sure that a given request will pass all of the other admission controllers.

The ordering of these calls can be seen below.

![Sequence diagram for kube-apiserver handling requests during the admission phase showing mutation webhooks, followed by validatingadmissionpolicies and finally validating webhooks. It shows that the continue until the first rejection, or being accepted by all of them. It also shows that mutations by mutating webhooks cause all previously called webhooks to be called again.](/docs/reference/access-authn-authz/admission-control-phases.svg)

## Why do I need them?

## How d …(trimmed)