The admission controllers documentation introduces how to use standard, plugin-style admission controllers. However, plugin admission controllers are not flexible enough for all use cases, due to the following:
Admission Webhooks (beta in 1.9) addresses these limitations. It allows admission controllers to be developed out-of-tree and configured at runtime.
This page describes how to use 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 and mutating admission webhook. With validating admission Webhooks, you may reject requests to enforce custom admission policies. With mutating admission Webhooks, you may change requests to enforce custom defaults.
Admission webhooks are essentially part of the cluster control-plane. You should write and deploy them with great caution. Please read the user guides for instructions if you intend to write/deploy production-grade admission webhooks. In the following, we describe how to quickly experiment with admission webhooks.
Ensure that the Kubernetes cluster is at least as new as v1.9.
Ensure that MutatingAdmissionWebhook and ValidatingAdmissionWebhook admission controllers are enabled. Here is a recommended set of admission controllers to enable in general.
Ensure that the admissionregistration.k8s.io/v1beta1 API is enabled.
Please refer to the implementation of the admission webhook
that is validated in a Kubernetes e2e test. The webhook handles the
admissionReview requests sent by the apiservers, and sends back its decision
admissionReview request can have different versions (e.g. v1beta1 or
v1 in a future version).
The webhook can define what version they accept using
admissionReviewVersions field. API server
will try to use first version in the list which it supports. If none of the versions specified
in this list supported by API server, validation will fail for this object. If the webhook
configuration has already been persisted, calls to the webhook will fail and be
subject to the failure policy.
The example admission webhook server leaves the
which defaults to
NoClientCert. This means that the webhook server does not
authenticate the identity of the clients, supposedly apiservers. If you need
mutual TLS or other ways to authenticate the clients, see
how to authenticate apiservers.
You may also deploy your webhooks outside of the cluster. You will need to update your webhook client configurations accordingly.
The following is an example
validatingWebhookConfiguration, a mutating webhook
configuration is similar.
apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingWebhookConfiguration metadata: name: <name of this configuration object> webhooks: - name: <webhook name, e.g., pod-policy.example.io> rules: - apiGroups: - "" apiVersions: - v1 operations: - CREATE resources: - pods scope: "Namespaced" clientConfig: service: namespace: <namespace of the front-end service> name: <name of the front-end service> caBundle: <pem encoded ca cert that signs the server cert used by the webhook> admissionReviewVersions: - v1beta1 timeoutSeconds: 1
The scope field specifies if only cluster-scoped resources (“Cluster”) or namespace-scoped resources (“Namespaced”) will match this rule. “*” means that there are no scope restrictions.
Note: When using
clientConfig.service, the server cert must be valid for
Note: Default timeout for a webhook call is 30 seconds but starting in kubernetes 1.14 you can set the timeout and it is encouraged to use a very small timeout for webhooks. If the webhook call times out, the request is handled according to the webhook’s failure policy.
When an apiserver receives a request that matches one of the
apiserver sends an
admissionReview request to webhook as specified in the
After you create the webhook configuration, the system will take a few seconds to honor the new configuration.
If your admission webhooks require authentication, you can configure the apiservers to use basic auth, bearer token, or a cert to authenticate itself to the webhooks. There are three steps to complete the configuration.
When starting the apiserver, specify the location of the admission control
configuration file via the
In the admission control configuration file, specify where the
MutatingAdmissionWebhook controller and ValidatingAdmissionWebhook controller
should read the credentials. The credentials are stored in kubeConfig files
(yes, the same schema that’s used by kubectl), so the field name is
kubeConfigFile. Here is an example admission control configuration file:
apiVersion: apiserver.k8s.io/v1alpha1 kind: AdmissionConfiguration plugins: - name: ValidatingAdmissionWebhook configuration: apiVersion: apiserver.config.k8s.io/v1alpha1 kind: WebhookAdmission kubeConfigFile: <path-to-kubeconfig-file> - name: MutatingAdmissionWebhook configuration: apiVersion: apiserver.config.k8s.io/v1alpha1 kind: WebhookAdmission kubeConfigFile: <path-to-kubeconfig-file>
The schema of
admissionConfiguration is defined
In the kubeConfig file, provide the credentials:
apiVersion: v1 kind: Config users: # DNS name of webhook service, i.e., <service name>.<namespace>.svc, or the URL # of the webhook server. - name: 'webhook1.ns1.svc' user: client-certificate-data: <pem encoded certificate> client-key-data: <pem encoded key> # The `name` supports using * to wildmatch prefixing segments. - name: '*.webhook-company.org' user: password: <password> username: <name> # '*' is the default match. - name: '*' user: token: <token>
Of course you need to set up the webhook server to handle these authentications.
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.