Certified Kubernetes Security Specialist (CKS) Preparation Part 7 — Supply Chain Security

If you have not yet checked the previous parts of this series, please go ahead and check Part1, Part2, Part3, Part4, Part5 and Part6.

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-apiserver binary, 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!