|
| 1 | +--- |
| 2 | +title: Admission Webhooks |
| 3 | +linkTitle: Webhook |
| 4 | +weight: 30 |
| 5 | +description: An in-depth walkthough of admission webhooks. |
| 6 | +--- |
| 7 | + |
| 8 | +## Create a validating or mutating Admission Webhook |
| 9 | + |
| 10 | +Admission webhooks are HTTP callbacks that receive admission requests and do something with them. It is registered with Kubernetes, and |
| 11 | +will be called by Kubernetes to validate or mutate a resource before being stored. There are two types of admission webhooks. |
| 12 | + |
| 13 | +#### 1. Validating admission webhook |
| 14 | + |
| 15 | +Validating webhooks can be used to perform validations that go beyond the capabilities of OpenAPI schema validation, |
| 16 | +such as ensuring a field is immutable after creation or higher level permissions checks based on the user that is making |
| 17 | +the request to the API server. It can reject the request, but it cannot modify the object that they are receiving in the request. |
| 18 | + |
| 19 | +#### 2. Mutating admission webhook |
| 20 | + |
| 21 | +Mutating webhooks are most frequently used for defaulting, by adding default values for unset fields in the resource on creation. |
| 22 | +They can modify objects by creating a patch that will be sent back in the admission response. |
| 23 | + |
| 24 | +For more background on Admission webhooks, refer to the [Kubebuilder documentation](https://book.kubebuilder.io/reference/admission-webhook.html) or the [official Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/). |
| 25 | +You can also refer to the [Kubebuilder webhook walkthrough](https://book.kubebuilder.io/cronjob-tutorial/webhook-implementation.html), which is similar in content to this guide. |
| 26 | + |
| 27 | +### Create Validation Webhook |
| 28 | + |
| 29 | +As an example, let's walk through the scaffolding of a validation webhook for the sample memcached operator. |
| 30 | + |
| 31 | +```sh |
| 32 | +$ operator-sdk create webhook --group cache --version v1alpha1 --kind Memcached --defaulting --programmatic-validation |
| 33 | +``` |
| 34 | + |
| 35 | +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/memcached_webhook.go`. |
| 36 | + |
| 37 | +```sh |
| 38 | +Writing kustomize manifests for you to edit... |
| 39 | +Writing scaffold for you to edit... |
| 40 | +api/v1alpha1/memcached_webhook.go |
| 41 | +``` |
| 42 | + |
| 43 | +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. |
| 44 | +In this case we have scaffolded both. |
| 45 | + |
| 46 | +After running the `create webhook` command the file structure would be: |
| 47 | + |
| 48 | +```sh |
| 49 | +├── Dockerfile |
| 50 | +├── Makefile |
| 51 | +├── PROJECT |
| 52 | +├── api |
| 53 | +│ └── v1alpha1 |
| 54 | +│ ├── memcached_webhook.go |
| 55 | +│ ├── webhook_suite_test.go |
| 56 | +├── config |
| 57 | +│ ├── certmanager |
| 58 | +│ │ ├── certificate.yaml |
| 59 | +│ │ ├── kustomization.yaml |
| 60 | +│ │ └── kustomizeconfig.yaml |
| 61 | +│ ├── default |
| 62 | +│ │ ├── manager_webhook_patch.yaml |
| 63 | +│ │ └── webhookcainjection_patch.yaml |
| 64 | +│ └── webhook |
| 65 | +│ ├── kustomization.yaml |
| 66 | +│ ├── kustomizeconfig.yaml |
| 67 | +│ └── service.yaml |
| 68 | +├── go.mod |
| 69 | +├── go.sum |
| 70 | +└── main.go |
| 71 | +``` |
| 72 | + |
| 73 | +The scaffolded file `api/v1alpha1/memcached_webhook.go` has method signatures which need to be implemented for the validation webhook. |
| 74 | + |
| 75 | +Following this, there are a few steps which need to be done in your operator project to enable webhhoks. This will involve: |
| 76 | + |
| 77 | +1. Implementing the required methods for Validating or Mutating webhook in `<kind>_webhook.go`. An example of such implementation is provided [here](https://book.kubebuilder.io/cronjob-tutorial/webhook-implementation.html). |
| 78 | + |
| 79 | +2. 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 [here](https://book.kubebuilder.io/cronjob-tutorial/running-webhook.html#deploy-webhooks). |
| 80 | + |
| 81 | +### Generate webhook manifests and enable webhook deployment |
| 82 | + |
| 83 | +Once your webhooks are implemented, all that’s left is to create the `WebhookConfiguration` manifests required to register your webhooks with Kubernetes: |
| 84 | + |
| 85 | +```sh |
| 86 | +$ make manifests |
| 87 | +``` |
| 88 | + |
| 89 | +## Run your operator and webhooks |
| 90 | + |
| 91 | +There are two ways to test your operator project with webhooks. |
| 92 | + |
| 93 | +#### Run locally |
| 94 | + |
| 95 | +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 [here](https://book.kubebuilder.io/cronjob-tutorial/running.html#running-webhooks-locally). |
| 96 | + |
| 97 | +#### Run as a Deployment inside the cluster |
| 98 | + |
| 99 | +Adding webhooks does not alter deploying your operator. For instructions on deploying your operator into a cluster, refer to the [tutorial](https://sdk.operatorframework.io/docs/building-operators/golang/tutorial/#2-run-as-a-deployment-inside-the-cluster). |
0 commit comments