Dynamic Admission Control [page]deterministic
In addition to [compiled-in admission plugins](/docs/reference/access-authn-authz/admission-controllers/), admission plugins can be developed as extensions and run as webhooks configured at runtime. This page describes how to build, configure, use, and monitor admission webhooks.
## What are admission webhooks?
Admission webhooks are HTTP callbacks that receive admission requests and do something with them. You can define two types of admission webhooks, [validating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) and [mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook). Mutating admission webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults. After all object modifications are complete, and after the incoming object is validated by the API server, validating admission webhooks are invoked and can reject requests to enforce custom policies.
> Note: Admission webhooks that need to guarantee they see the final state of the object in order to enforce policy should use a validating admission webhook, since objects can be modified after being seen by mutating webhooks.
## Experimenting with admission webhooks
Admission webhooks are essentially part of the cluster control-plane. You should write and deploy them with great caution. Please read the [user guides](/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server) for instructions if you intend to write/deploy production-grade admission webhooks. In the following, we describe how to quickly experiment with admission webhooks.
### Prerequisites
* Ensure that MutatingAdmissionWebhook and ValidatingAdmissionWebhook admission controllers are enabled. [Here](/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use) is a recommended set of admission controllers to enable in general.
* Ensure that the `admissionregistration.k8s.io/v1` API is enabled.
### Write an admission webhook server
Please refer to the implementation of the [admission webhook server](https://github.com/kubernetes/kubernetes/blob/release-1.21/test/images/agnhost/webhook/main.go) that is validated in a Kubernetes e2e test. The webhook handles the `AdmissionReview` request sent by the API servers, and sends back its decision as an `AdmissionReview` object in the same version it received.
See the [webhook request](#request) section for details on the data sent to webhooks.
See the [webhook response](#response) section for the data expected from webhooks.
The example admission webhook server leaves the `ClientAuth` field [empty](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/images/agnhost/webhook/config.go#L38-L39), which defaults to `NoClientCert`. This means that the webhook server does not authenticate the identity of the clients, supposedly API servers. If you need mutual TLS or other ways to authenticate the clients, see how to [authenticate API servers](#authenticate-apiservers).
### Deploy the admission webhook service
The webhook server in the e2e test is deployed in the Kubernetes cluster, via the [deployment API](/docs/reference/generated/kubernetes-api//#deployment-v1-apps). The test also creates a [service](/docs/reference/generated/kubernetes-api//#service-v1-core) as the front-end of the webhook server. See [code](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/e2e/apimachinery/webhook.go#L748).
You may also deploy your webhooks outside of the cluster. You will need to update your webhook configurations accordingly.
### Configure admission webhooks on the fly
You can dynamically configure what resources are subject to what admission webhooks via [ValidatingWebhookConfiguration](/docs/reference/generated/kubernetes-api//#validatingwebhookconfiguration-v1-admissionregistration-k8s-io) or
…(trimmed)