Back to Basics: Kubernetes Admission Webhooks
Kubernetes’s containerized services environment is extensive. But there are times when an additional configuration is required to optimize the infrastructure fully. Several admins need the customizability offered by admission webhooks. In this article, you will understand Kubernetes admission webhooks, how to use them, and when you should use them.
Admission Webhooks
Webhooks are the type of customized controller that can validate or change objects. Admission webhooks are HTTP callbacks that are triggered when requests are made. The Kubernetes middleware can be configured to contact the service when certain operations are performed on certain Kubernetes resources. These plugins eventually control clusters and determine how Kubernetes uses them. The webhook can inspect newly created pods and take one of three actions: allow the request, reject the request, or modify it by returning a mutated or changed version.
Kubernetes admission controller is a block of code that intercepts requests to the Kubernetes API before the object is persisted, but after the user has been authenticated and authorized.
Within Kubernetes, controllers and webhooks exist separately. The controllers are compiled into the Kubernetes apiserver binary and can only be provisioned by the cluster-admin. Webhooks are configured appropriately within the API because they directly influence HTTP activity. Webhooks are also adaptable and simple to code in any language or framework, allowing Kubernetes admission controllers to integrate with any third-party code.
Admission controllers have the ability to validate or mutate, or do a combination of the two. The objects associated with the requests validation controller cannot be changed by them, but they can be by mutating controllers.
Configuring Kubernetes Admission Webhooks
When configuring admission webhooks, things to keep in mind include: checking to see whether admission webhook controllers are permitted in the cluster and, if so, configuring them. An HTTP callback that will handle admission requests can be written (this can be a simple HTTP server deployed to the cluster or a serverless function). Configure the admission webhook through the ValidatingWebhookConfiguration and MutatingWebhookConfiguration resources.
In various cases, webhooks can be used to create configurations for admission for resources by cluster admins. Possible cases that admins can face include usage of RBAC policies, customization of created or modified resource limitations, unauthorized personnel being unable to add or delete resources, sidecar container injections to implement more logging, and surveying and traffic controllers.
You can also choose to allow your admission webhooks to return messages of caution. The cautionary code 299 can be programmed to appear in warning headers to the requesting server. Cautions can be sent with responses based on whether the request has been accepted or denied.
The thing that you have to keep in mind when configuring messages are (a) your message must not have the prefix ”warning” in it, and (b) there should be a limit of 120 characters in your caution response and these characters should explain problems that the server making the API request should avoid or correct.
Kubernetes Apiserver Authentication
If your admission webhooks necessitate authentication, you can customize the apiserver to utilize basic authentication, tokens, or certificates to connect to the webhooks.
The steps for completing the configuration include the following.
When starting the apiserver, use the — admission-control-config-file flag to specify where the admission control configuration file is located. Indicate where the MutatingAdmissionWebhook and ValidatingAdmissionWebhook controllers should read the credentials in the admission control configuration file. The name given to the field is called kubeConfigFile because the details are stored in kubeConfig files. Finally, enter the credentials in the kubeConfig file.
If we have a recently created webhook config that doesn’t support any of the AdmissionReview versions that can be used by the apiserver, only the first version gets sent. And, attempted calls to the webhook fail and are subject to the failed policy.
Once the apiserver has determined that a request should be routed to a webhook, it must determine how to reach the webhook. This needs to be included in the webhook configuration’s clientConfig stanza. Webhooks can be accessed via a URL or a service reference, and they can include a custom CA bundle for TLS connection verification if desired.
In a production cluster, it’s critical to properly manage your TLS certificates, especially private keys, so you might want to use cert-manager or store your keys in a vault rather than as plain Kubernetes secrets. The most important thing to remember is to include the corresponding CA certificate later in the webhook configuration so that the apiserver knows it should accept it.
Conclusion
Admission webhooks give a cluster administrator some of the tools required to enforce cluster security policies. You have been introduced to some of Kubernetes’ basic and a few advanced features, such as admission webhooks and how admission controllers implement them. Admission control is an important tool for securing Kubernetes clusters that you should have in your toolbox if you handle clusters.
