Kubernetes Validating Webhook Deployment

In part one of this series we demonstrated how to construct a Kubernetes validating webhook to extend Kubernetes for our custom resource validations. In this simple example we will require a team label to be present on all namespaces. The subject of this post is to take our simple example and deploy it to a cluster for a functional test.

As in the previous post, the example code is located here for the impatient. We will begin by looking at the ValidatingWebhookConfiguration resource. This configuration describes the resources and events Kubernetes will invoke your webhook service endpoint for. In the previous post I mentioned the implementation language of your webhook is not important to Kubernetes. This configuration demonstrates that Kubernetes simply needs a service namespace, name and path to invoke. This is simple RESTful design, any implementation that returns the proper response is acceptable.

In our simple example above, we are asking Kubernetes to invoke our service at the defined namespace, name and path. Kubernetes will invoke this endpoint if a namespace resource is created or updated. The resources and events are defined in the rules section, and service information is provided in the clientConfig section. The most challenging element of the clientConfig section is caBundle. You must serve the endpoint over HTTPS and the certificate authority bundle must be provided here to validate the certificate served by your endpoint.

You can generate certificates in many ways. You can leverage self signed certificates or cluster signed certificates or even certificates issued by your organization. For this simple example we will leverage the certificate authority within the cluster we are deploying to and Kubernetes resources to generate certificates. Please review the script located here to see a full example of generating a CertificateSigningRequest and a secret to be consumed by the application to serve the HTTPS endpoint. Once this certificate is issued and secret created, we populate the certificate authority bundle from the cluster itself. This data replaces the CA_BUNDLE placeholder above with a simple sed command.

So we have the mechanics to generate a certificate and populate some YAML but how do we do this in an automated way? I choose to leverage Helm for this task. Helm provides hooks to order resource creation which allows us to create a job that generates the certificates, populates the certificate authority bundle and submits the ValidatingWebhookConfiguration resource. This is difficult to get within a screen capture so I would recommend viewing the predeploy.sh script here.

The predeploy.sh script is packaged into a Docker image and is executed leveraging the helm pre-install hook as a Job (see above) to ensure the environment is prepared prior to our webhook deployment. Once completed, our standard Kubernetes resources are created such as the deployment and service. The YAML leveraged by Helm is located under the chart directory at the base of the repository. We can deploy this chart leveraging a simple command at the base of the repository.

Finally, we are ready to functionally test this webhook. Let’s start with a simple namespace creation with no team label.

Perfect, this namespace has been rejected with our expected message. Now, let’s attempt to create a namespace with the required label.

YES! As expected, we can create namespaces if our validations have been met. Now we can leverage this pattern for more interesting extensions. I leverage this exact pattern for mutating as well as validating webhook deployment. I hope this trivial example helps you deploy your own webhooks!