CKS — Supply Chain Security the domain the graders like

Four scored bullets, four tools, and one admission plugin that fails open if you get the default wrong.

Every task in this domain produces a file or an object the grader can check. That is why it is worth the drill.

§IFrame

Two CKS domains are closed on this arc. Minimize Microservice Vulnerabilities came in on 07-26 with Pod Security Standards and the securityContext. Cluster Setup came in on 08-01 with kube-bench, ingress TLS, and metadata protection. Supply Chain Security is the biggest one left, and it is the one the exam graders like, because every task in it produces a file or an object they can check without ambiguity.

The blueprint names four things: minimize base image footprint, secure the supply chain by whitelisting allowed registries and signing images, use static analysis on user workloads, and scan images for known vulnerabilities.

Today's Ops lesson carried the concepts at depth. This one drills the terminal. Rice's chapter on images is the reading behind it, and the chapter on vulnerabilities supplies the caution the exam rewards you for already knowing.

§IIMinimize base image footprint

The scored move is arithmetic. Fewer packages in the image means fewer CVEs in the scan report, and Rice's Installed Packages section is blunt about the cause: most of what a scanner reports came from the base image, not from your code.

Four techniques, in the order they cut the most.

Pick a smaller base. alpine over ubuntu. distroless over alpine where the language runtime allows it. scratch for a static Go binary, which Burns and co-authors flag in the image-size section as the case where the container carries almost nothing to attack.

Multi-stage build. The compiler, the package manager cache, and the build dependencies live in the first stage and never reach the second. This is the single largest cut on most images.

FROM golang:1.23 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /out/gateway ./cmd/gateway

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/gateway /gateway
USER 65532:65532
ENTRYPOINT ["/gateway"]

Run as a named non-root user. USER 65532:65532 in the Dockerfile, and a matching runAsNonRoot: true in the Pod spec. The exam's Dockerfile-fix questions score this and the base-image pin together.

Pin the base image, never latest. Rice's best-practices section lists this beside the secrets rule. A FROM ubuntu:latest is a build that produces a different artifact every week.

§IIIScan images for known vulnerabilities

trivy is the tool the exam expects. The Bootcamp's q18 gives the shape exactly: scan a list of images for HIGH and CRITICAL, write every result to one file.

for img in ubuntu:18.04 registry.k8s.io/kube-apiserver:v1.24.0 postgres:12; do
  trivy image --severity HIGH,CRITICAL "$img" >> /opt/trivy-vulnerable.txt
done

Three flags carry the domain. --severity HIGH,CRITICAL filters. --exit-code 1 turns the report into a gate, which is what a pipeline task is really asking for. --quiet keeps progress noise out of the file when a task says store the output, and graders do parse those files.

The other common task shape: scan the images running in a namespace and delete the workloads whose images fail. Get the image list from the Pods, then scan each.

kubectl get pods -n production \
  -o jsonpath='{.items[*].spec.containers[*].image}' | tr ' ' '\n' | sort -u

Rice's cautions are the exam's discriminators between a pass and a strong pass. A scan is a comparison against a database with a date on it. Some findings are marked won't fix by the distribution maintainer and will never clear, so a policy of zero findings fails to ship anything. And zero-days exist before the database knows them, which is why Regular Scanning argues for re-scanning what is deployed rather than trusting the build-time report.

kubesec covers the other half of static analysis, and it scans manifests rather than images.

kubesec scan pod.yaml

It scores a Pod spec on securityContext fields: runAsNonRoot, readOnlyRootFilesystem, dropped capabilities, privileged, hostNetwork. That is the 07-26 restricted-profile checklist read back by a tool. When a task says analyze the workload rather than scan the image, reach for kubesec.

§IVSBOM generation

The Bootcamp's q44 is the clearest statement of what the exam wants here. Two tools, two formats, one scan-of-an-SBOM.

bom generate -o /opt/candidate/13/sbom1.json --format json \
  --image registry.k8s.io/kube-apiserver:v1.32.0

trivy image --format cyclonedx -o /opt/candidate/13/sbom2.json \
  registry.k8s.io/kube-controller-manager:v1.32.0

trivy sbom /opt/candidate/13/sbom_check.json -o /opt/candidate/13/sbom_result.json

Hold the pairing. bom is the Kubernetes SIG tool and produces SPDX. trivy --format cyclonedx produces CycloneDX. Task text names the format, and picking the wrong tool for the named format is the whole failure mode.

The third command is the one candidates skip. trivy sbom takes an existing SBOM as input and scans it, which is faster than re-pulling the image and is how a fleet answers which of our four hundred images contain this package when a CVE lands. Rice's argument for regular scanning is what an SBOM makes cheap.

Verify by looking. An SPDX file carries spdxVersion and SPDXID fields; a CycloneDX file carries bomFormat and specVersion. One head -5 tells you which you produced.

§VWhitelisting registries: the ImagePolicyWebhook

The blueprint bullet says secure your supply chain: whitelist allowed image registries. Two mechanisms answer it, and the exam prefers the built-in one.

ImagePolicyWebhook is an API-server admission plugin. Three files, and every one of them is a scored step.

First, enable the plugin and point it at a config file:

- --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook
- --admission-control-config-file=/etc/kubernetes/confcontrol/admission_config.yaml

Second, the admission configuration naming the plugin's own config:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    configuration:
      imagePolicy:
        kubeConfigFile: /etc/kubernetes/confcontrol/kubeconf
        allowTTL: 50
        denyTTL: 50
        retryBackoff: 500
        defaultAllow: false

Third, the kubeconfig giving the API server the webhook's URL and CA.

defaultAllow: false is the whole question. The task says deny all non-compliant images, and the default is true, which means an unreachable backend admits everything. Flip it to false and an unreachable backend blocks everything. That is the implicit deny the grader checks, and it is the same fail-closed choice the day's Dev lesson makes with failurePolicy: Fail.

Gatekeeper or Kyverno is the other mechanism. Burns and co-authors walk the Gatekeeper install and the admission flow in the policy chapter, and the K8sAllowedRepos constraint template is the registry-prefix answer. The exam is likelier to hand you a broken ImagePolicyWebhook than to have you install Gatekeeper under time pressure. Know both; expect the plugin.

Signing sits in this bullet too. Rice's Signing Images section gives the concept: a signature binds a digest to a builder identity. The current tooling is cosign for signing and a policy controller for admission-time verification. This is the one corner where the shelf and the Bootcamp set both come up empty, so treat it as concept-level for the exam and read the tool docs before sitting.

§VIExam drill

§VIIThe Trio Interlock

Ops carried the four attach points and the AKS worked example, which is where the registry boundary gets drawn in a real cloud. Dev built the resolver and the webhook that turns a tag into a digest and hands the author the string to paste. This lesson is the same ground at exam pace, by hand, against a clock.

Coverage note for the next CKS day: Cluster Hardening (15%), System Hardening (15%), and Monitoring, Logging and Runtime Security (20%) are the three CKS domains still untouched by this arc. The Bootcamp set carries falco, seccomp, AppArmor, and audit-logging questions against all three.

Set a twelve-minute timer. Do the three SBOM commands in §IV from memory, then the ImagePolicyWebhook three-file setup in §V without scrolling back. The step you forget is almost certainly defaultAllow.