Security in a cloud-native environment is only as strong as its weakest link. A recent security audit revealed a critical gap: container images were being deployed to our cluster with outdated software versions harboring numerous vulnerabilities.

To solve this, we are implementing an ImagePolicyWebhook. By configuring an Admission Controller to point to a webhook backend image scanner, we can intercept deployment requests and reject any image that doesn't meet our security standards.

The Solution

In this walkthrough, we will configure the Kubernetes API server to communicate with an existing scanner (like Trivy) via a webhook.

1. Configure the Admission Controller

First, we need to define the configuration for the ImagePolicyWebhook plugin. This file tells Kubernetes where to find the backend credentials and how to behave if the scanner is unreachable.

Edit the configuration file:

sudo vi /etc/kubernetes/admission-control/admission-control.conf

Paste the following configuration:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
 configuration:
 imagePolicy:
 kubeConfigFile: /etc/kubernetes/admission-control/imagepolicy_backend.kubeconfig
 allowTTL: 50
 denyTTL: 50
 retryBackoff: 500
 defaultAllow: false # Fails closed for security

👁 changes

Pro Tip: Setting defaultAllow: false ensures that if the scanner is down, no unverified images are allowed into the cluster.

2. Point the Kubeconfig to the Backend Webhook

The Admission Controller needs a kubeconfig file to know the endpoint of the scanning service.

Edit the kubeconfig:

sudo vi /etc/kubernetes/admission-control/imagepolicy_backend.kubeconfig

Update the server endpoint:
Locate the server line under the cluster section and set it to:

server: https://acg.trivy.k8s.webhook:8090/scan

👁 trivy

3. Enable the Admission Control Plugin

Now, we must tell the Kubernetes API server to actually use the plugin we just configured.

Edit the kube-apiserver manifest:

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

Update the flags:
Scroll down to the --enable-admission-plugins section and add ImagePolicyWebhook:

--enable-admission-plugins=NodeRestriction,ImagePolicyWebhook

👁 changes

Once you save this file, the API server will automatically restart to apply the changes.

Testing the Implementation

The "Good" Pod

Create a Pod using an image that is known to be clean:

kubectl create -f good-pod.yml

Result: The Pod should be created successfully.

The "Bad" Pod

Now, attempt to deploy an image with known vulnerabilities:

kubectl create -f bad-pod.yml

👁 error

Result: The creation will fail! You will receive an error message indicating that the image was rejected by the ImagePolicyWebhook due to security vulnerabilities.

Conclusion

By shifting security to the Admission Control phase, you ensure that no vulnerable code ever reaches your production nodes. Automation like this turns "security" from a manual checklist into an unbreakable gatekeeper.

Happy (and secure) Kube-ing! 🛡️ ☸️