When a Kubernetes manifest is applied, the request goes through has various stops along the way. Part of the requests life cycle is the admission controllers. The purpose of the admission controller is to intercept the requests and process them. The admission controllers occur after the request has been authorization and authenticated, but before the request object has been persisted.
There are two types of admission controllers:
- Mutating will allow you to mutate the request based on certain criteria you set
- Validating will either allow or deny a request based on your criteria. The controller will not mutate the request as it was done prior to the validating controller.
By default, Kubernetes comes with a range of admission controllers that each have a unique purpose. You can read about these controllers here.
You also have the option to enable, or disable, certain admission controllers. This can be done by adjusting either the enable-admission-plugins or disabled-admission-plugins flag on the api server. Both of these flags take a comma separated list of admission controllers.
kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...
kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...
Why are these useful?
The reason these admission controllers are useful is they allow you to put guard rails in place.
Let’s look at the DefaultStorageClass admission controller. This controller has a mutating behavior as if a user does not define a storage class, it will adjust the request and add one. This improves user experience, and avoids frustration when pods don’t deploy from a forgotten storage class.
Custom Admission controllers
Now while the default admissions controllers are useful, writing custom mutation and validation admission webhooks is helpful.
There are various policy agents, such as Kyverno or Open Policy Agent, that let you hook into the admission controller and allow you to deploy your own admission webhooks. These allow you to define your own custom criteria to how manifests
An example validating policy could be that all pod images must come from a docker hub. We should deny any pod request that comes through requesting an image from any other container registry.
Another example, but this time a mutating policy could watch all manifests should have a specific annotation applied to them. The mutating policy would then add the annotation if it doesn’t exist.
Or you can have a mutating policy that will add a minimum size storage to any PVCs requested of 10Gb. If the requests PVC is less than 10Gbs adjust the request to 10Gb.
Wrapping up
The default admission controllers that come with Kubernetes are useful to put up safeguards. However, custom admission controllers allow greater flexibility into putting safe guards and rules in place for all Kubernetes requests.