Certified Kubernetes Security Specialist (CKS) Preparation Part 7 — Supply Chain Security
In this article, I would focus on the preparation around supply chain security in CKS certification exam.
Docker Image Management
To be honest, I have never really gotten familiar with Docker image as I seldom get the chance to go to that stage of the pipeline. However, in this exam, we would need to have the general idea of how Docker image works and what would be the practice of making this process safe and efficient.
Basically, the two principles below are for reducing Docker image size. This article provides great explanation around this.
- Light-weight Image as base
- Multi-stage Build
In practice, we could test buy creating a container running with original Docker file and we are seeing the image consists around 690 MB.
If we apply the 2 principles above,
we would see Docker image size being hugely reduced. Mainly, this is because from the second stage (stage 1), it just acquires that components needed from the first stage (stage 0) and that removes a lot of unnecessary files.
With 4 principles below, we could make Docker image more secure.
- Use specific package versions
- Do not run as root
- Make file system read only
- Remove shell access
Make sure the Docker image still runs after updating the Dockerfile.
Image Security — Trivy
Since we would be running all kinds of Docker image within containers (Pods), one extremely important thing is to ensure container images are always without security concern. Trivy was developed for this sole purpose and it is extremely easy to use.
Trivy could be installed through OS and run as a service or simply run the service inside a Docker container. General guidance on Trivy commands to scan container images. In this article, we would run Trivy inside a Docker container.
docker run ghcr.io/aquasecurity/trivy:latest image nginx
Search container images with CRITICAL severity.
docker run ghcr.io/aquasecurity/trivy:latest image nginx | grep CRITICAL
Once we get the details on container image vulnerability, we could look it up in the national vulnerability database.
Maybe we could take a look at the container images kube-apiserver is using.
- kubectl get pods -n kube-system | grep api
- kubectl get pods kube-apiserver-cks-master -n kube-system -o yaml | grep image
docker run ghcr.io/aquasecurity/trivy:latest image k8s.gcr.io/kube-apiserver:v1.20.2
At the end of the day, please ensure all services and applications are running on container images with no major security concerns.
Image Policy Webhook
Image Policy Webhook is the connecting piece of letting backend admission controller to go through external server for checking image security and integrity before making any CRUD operation on K8s clusters.
An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. The controllers consist of the list below, are compiled into the
kube-apiserverbinary, and may only be configured by the cluster administrator. In that list, there are two special controllers: MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the mutating and validating (respectively) admission control webhooks which are configured in the API.
— Quoted from here
First, we add “ImagePolicyWebhook” at the end of admission plugins.
sudo nano /etc/kubernetes/manifests/kube-apiserver.yaml
Configure host path to ensure Image Policy Webhook could actually get to the directory holding admission configuration files.
After setting kube-apiserver to point to the right path for setting up admission configuration, please head over to that specific folder and file. The information within the file should show how Image Policy would be operating on this cluster.
We notice there is K8s configuration setup, which is for admission controller to have corresponding credentials to communicate with external image-checking server and kube-apiserver.
After setup everything correctly, if we try to deploy an image without security-compliant container image, we should be error messages similar to below
Error from server (Forbidden): pods "test" is forbidden: Post "https://xxxx:xxxx/xxxx?timeout=30s": dial tcp:....
For more details on how to setup and what to setup in Image Policy Webhook, please check this section of the official documentation.
That briefly covers the how to avoid having vulnerable container image in K8s cluster. One thing I did not include in this article is using Open Policy Agent (OPA) for only using whitelisted container images for deploying applications/services, because I think if you have followed this series, you already have a general idea on how to setup that in OPA! Happy learning!