Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: webhook.md

title: Admission Webhooks linkTitle: Webhook weight: 30 description: An in-depth walkthrough of admission webhooks. Admission webhooks are HTTP callbacks that receive admission requests and do something with them. It is registered with Kubernetes, and will be called by Kubernetes to validate or mutate a resource before being stored. There are two types of admission webhooks. Validating webhooks can be used to perform validations that go beyond the capabilities of OpenAPI schema validation, such as ensuring a field is immutable after creation or higher level permissions checks based on the user that is making the request to the API server. It can reject the request, but it cannot modify the object that they are receiving in the request. Mutating webhooks are most frequently used for defaulting, by adding default values for unset fields in the resource on creation. They can modify objects by creating a patch that will be sent back in the admission response. For more background on Admission webhooks, refer to the or the . You can also refer to the , which is similar in content to this guide. As an example, let's walk through the scaffolding of a validation webhook for the sample memcached operator. ```sh $ operator-sdk create webhook --group cache --version v1alpha1 --kind Memcached --defaulting --programmatic-validation ``` After, `create webhook` command, the following message will appear on the terminal. It scaffolds out `api/<version>/<kind>webhook.go` file. In this example, it would be `api/v1alpha1/memcachedwebhook.go`. ```sh Writing kustomize manifests for you to edit... Writing scaffold for you to edit... api/v1alpha1/memcached_webhook.go ``` The `--defaulting` flag will scaffold the resources required for a mutating webhook, and the `--programmatic-validation` flag will scaffold the resources required for a validating webhook. In this case we have scaffolded both. After running the `create webhook` command the file structure would be: ```sh Dockerfile Makefile PROJECT api v1alpha1 memcached_webhook.go webhooksuitetest.go config certmanager certificate.yaml kustomization.yaml kustomizeconfig.yaml default managerwebhookpatch.yaml webhookcainjection_patch.yaml webhook kustomization.yaml kustomizeconfig.yaml service.yaml go.mod go.sum main.go ``` The scaffolded file `api/v1alpha1/memcached_webhook.go` has method signatures which need to be implemented for the validation webhook. Following this, there are a few steps which need to be done in your operator project to enable webhooks. This will involve: Implementing the required methods for Validating or Mutating webhook in `<kind>_webhook.go`. An example of such implementation is provided . Uncommenting sections in `config/default/kustomization.yaml` to enable webhook and cert-manager configuration through kustomize. Cert-manager (or any third party solution) can be used to provision certificates for webhook server. This is explained in detail . Note If OLM is being used to deploy the operator, then the section prefixed with `. Once your webhooks are implemented, all thats left is to create the `WebhookConfiguration` manifests required to register your webhooks with Kubernetes: ```sh $ make manifests ``` There are two ways to test your operator project with webhooks. Technically, the webhooks can be run locally, but for it to work you need to generate certificates for the webhook server and store them at `/tmp/k8s-webhook-server/serving-certs/tls.{crt,key}`. For more details about running webhook locally, refer . Adding webhooks does not alter deploying your operator. For instructions on deploying your operator into a cluster, refer to the .