Hands-on Lab·Certified Kubernetes Security Specialist
Static Analysis of a Dockerfile
The manifest is the last place to fix a workload's security and the Dockerfile is nearly the first. This guide scans one that looks perfectly ordinary, finds five problems, and shows how three of them are the base-image argument in a different form.
Supply Chain Security Guide 31 of 40 Intermediate
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 14 min
trivy config scans Dockerfiles with DS- rules alongside the KSV- rules it applies to manifests, so one binary covers both artefacts.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA6001 | 192.168.0.46 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE01 | 192.168.0.47 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE02 | 192.168.0.48 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when the fix belongs further upstream than the manifest. This matters because the Dockerfile is where most of a workload's security is actually decided, and a scanner reads one in seconds.
- scanning the six-line Dockerfile everyone has written, and reading what a scanner makes of it
- reading the finding that matters most, in full
- rewriting it, and measuring the same checks all over again
Before you start
- guide 30 - the same tool, one artefact earlier.
- guide 25 - the argument three of these findings make.
-
The Dockerfile everyone has written
-
The one that matters most
-
Fix it and measure again