Image Policy Webhook is a native Kubernetes admission plugin that enforces security policies by validating container images before they are deployed. This ensures that only trusted and compliant images run in your environment. This will take the image that is attempted to be applied compare against predefined policies, and if those policies allow the image to be deployed it will be deployed if not, it is rejected. This vetting process, along with proactive policy creation and enforcement forms the backbone of cluster security– catching potential misconfigurations before they manifests into real-world vulnerabilities.
Getting Started
For the use of ImagePolicyWebhook assuming you are using a managed cluster such as Amazon Web Services (Elastic Kubernetes Service), Azure Kubernetes Service or Google Kubernetes Engine these settings might differ as this is referencing and using kubeadm.
If you want to explore this in GKE check out the documentation on Binary Authorization Documentation
If you are using Azure Kubernetes Service this is fairly in the same direction that validates sign images with Image Integrity.
Finally if you are using Amazon Web Services this documentation covers the best practices of image security this recommends the use of Kyverno which is a OSS project that can assist enforcing OPA.
Requirements to replicate this in your environment running Kubernetes
- Kubeadm (v1.31.0) is running
- ImagePolicyWebhook Enabled on (admission plugin)
- Kubeconf pointed to the configuration
- KillerCoda has a lab for this if you want a browser experience
The configuration from the documentation will show the following now when we navigate to our cluster in Kubernetes we need to annotate and update the kube-apiserver to pick up the admissions plugin, policy file along with our volume and volumeMounts. This will make more sense when we reference the setup in the cluster.
cd /etc/kubernetes/manifests
--> kube-apiserver.yaml (this is our file)
Once we navigate we can see a few items first we have the luck of the policywebhook folder created but should you do this from the start a few items to unpack in this folder.
admission_config.json (which we'd edit)
apiserver-client-cert.pem (cert representing apiserver client)
external-cert.pem (external service cert)
kubeconf (our kubeconf that is used and referenced)
external-key.pem (external key to service)
apiserver-client-key.pem (apiserver client key)
# Notice we are operating with both a certificate and a key for this method
So if we use vim/nano to edit our file we see a few items that we’ve added we’ve pointed our Kubernetes Config File to the appropriate area where our kubeconf resides. We’ve also altered the behavior of default allow to false and updated the allowTTL to 100 this is how our admission_config.json should look now we’ve updated it.
Now we’ve partially updated part of our policy web hook now lets take a look at the other files to ensure the correct configuration is annotated.
cat kubeconf (assuming we are still in ./policywebhook)
We can see the annotation to help us is that in the question we have to change our external service which is the https://localhost:1234 for the server also notice the referenced certificates are already filled for us.
We can see we have our configuration file defined now we have to update the kube-apiserver to pick up the changes navigate to the Kubernetes manifests folder.
cd /etc/kubernetes/manifests
# Make a backup of the kube-apiserver.yaml
cp kube-apiserver.yaml kube-apiserver.yaml.ori We start with first checking for the enablement of ImagePolicyWebhook this is under the –enable-admission-plugins flag.
We update the ImagePolicyWebhook in the enable-admission-plugins and also check the config file to point to our previous folder with our configuration which appears correct.
We also if we are not lucky in the sense of having the file with a volumeMount we’d have to define these however these are already picked up for us. Check below the configuration.
After we have these files updated and configured we can run a Ctrl + X to save our changes then run the following to check on API Server status.
watch crictl psWe can test our solution with something simple to send a request.
kubectl run nginx --image=nginx
We can see the enforcement is in place and this action is forbidden. Wrapping up this demo delete any components associated with this and tear down your cluster.
Summary
Utilizing an Admission Controller for image validation is essential to ensuring that only trusted and compliant container images make it into your Kubernetes cluster. By proactively enforcing strict policies at the admission phase, this gatekeeping mechanism helps prevent vulnerabilities and unauthorized configurations before they impact your infrastructure. While this specific blog post utilizes the native ImagePolicyWebhook many admission controllers exist that simplify this configuration such as Kyverno don’t feel limited as the concept exists beyond this specific context. Limiting the ability of what is allowed is a first step in minimizing the attack surface.