CKS Supply Chain Security Practice Question
You are a security engineer at a fintech startup. The company runs a Kubernetes cluster in production with hundreds of microservices. Recently, a container image from a public registry was compromised, and the attacker injected a backdoor that exfiltrated customer data. The CISO mandates that all images must come from an internal registry that only stores approved, scanned, and signed images. Currently, developers build images locally and push them to Docker Hub, then reference those images in Kubernetes manifests. You have deployed Harbor as a private registry with vulnerability scanning and Cosign for signing. However, you notice that some pods are still running images directly from Docker Hub. You need to enforce that only images from your internal Harbor registry can be used in the cluster. You cannot change the Kubernetes manifests immediately because of a large backlog. You have access to the cluster's kubelet configuration and can modify cluster-level components. Which single action will most effectively block any pod that tries to use an image not hosted on your internal registry?
⚠ Common exam trap
CNCF often tests the distinction between admission control (webhooks) and runtime enforcement (container runtime configuration), where candidates mistakenly choose an admission webhook because it seems like a direct policy enforcement tool, but the question explicitly states that manifests cannot be changed immediately, making runtime-level enforcement the only viable option to block pulls without modifying existing resources.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure the containerd configuration on each node to use Harbor as a mirror for all registries and set endpoint to Harbor only, disabling direct pull from public registries.
Configuring containerd to use Harbor as a mirror for all registries and setting the endpoint to Harbor only effectively blocks pulls from any external registry at the container runtime level. This approach works even if Kubernetes manifests reference Docker Hub images, as the kubelet will redirect all image pull requests to the internal Harbor registry, preventing direct pulls from public registries. It enforces the policy without requiring immediate changes to existing manifests, which aligns with the constraint of not modifying them due to a large backlog. Option D (admission webhook) would require either modification of existing manifests or the webhook to deny pods that do not use the internal registry, but since manifests cannot be changed immediately, this would not affect already running pods unless they are recreated, making it less effective than runtime configuration. Option B (NetworkPolicy) only blocks network traffic but does not prevent the kubelet from pulling images from Docker Hub if the registry is reachable via a different path, and cached images can still be used.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enforce a PodSecurityStandard that restricts containers from running with root privileges.
Why it's wrong here
Enforcing a PodSecurityStandard that restricts containers from running with root privileges (e.g., the restricted profile) is a runtime security control that limits privilege escalation and user capabilities after the image has already been pulled and executed. It does nothing to inspect or validate the registry from which the image originates, so a pod using a malicious or unapproved external image could still be scheduled and run as long as the container runs as a non-root user. Thus, it addresses container runtime hardening, not image supply chain source enforcement, and is orthogonal to the requirement of blocking public registry pulls.
- ✗
Apply a Kubernetes NetworkPolicy that blocks egress traffic from nodes to Docker Hub.
Why it's wrong here
A NetworkPolicy blocks egress traffic but image pulls from the kubelet to a registry often bypass network policies if the traffic is on the node's network or uses a proxy. Moreover, cached images on the node can still be used even if registry access is blocked. This option is not reliable for enforcing image source.
- ✓
Configure the containerd configuration on each node to use Harbor as a mirror for all registries and set endpoint to Harbor only, disabling direct pull from public registries.
Why this is correct
Configuring containerd to use Harbor as a mirror and setting endpoint to Harbor only forces all image pulls to go through the internal registry. This works at the runtime level and doesn't require changes to manifests, making it the most immediate and effective solution.
- ✗
Deploy an admission webhook (e.g., OPA/Gatekeeper) that denies pods whose image registry is not the internal Harbor.
Why it's wrong here
An admission webhook like OPA/Gatekeeper can deny pods based on image registry, but it requires modifying pod specifications (e.g., adding labels or annotations) or making the webhook reject pods that don't meet criteria. Since manifests cannot be changed immediately, many existing pods would continue to run with external images unless they are recreated. This option is not as effective as runtime enforcement for the given constraint.
Go deeper
Related to this question
Learn chapter
Kubernetes Security Fundamentals
Key term
Image Scanning
Image scanning is the automated process of inspecting container images for known vulnerabilities, misconfigurations, and malware before they are deployed into production environments.
Key term
Image Signing and Verification
Image signing and verification is the process of digitally signing a container image to prove its origin and integrity, and then checking that signature before using the image to ensure it was not tampered with.
About these practice questions
Courseiva writes every CKS question from scratch — 114 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.