CKS Supply Chain Security — Timed 10 Questions

Question 1

Which TWO of the following are best practices for securing the container supply chain?

Accepted Answer

Scan images for vulnerabilities in a CI pipeline before deploying.. Scanning images for vulnerabilities in a CI pipeline before deployment is a best practice because it catches known CVEs early, preventing vulnerable images from reaching production. Tools like Trivy, Clair, or Grype integrate into CI/CD to enforce policy gates, ensuring only compliant images proceed.

Answer

Embed API keys directly in container images for authentication.

Answer

Allow all images from any registry without verification to speed up development.

Answer

Use mutable tags like 'latest' for easier updates.

Question 2

Which THREE of the following are required to implement a secure software supply chain using Kubernetes native features?

Accepted Answer

Use vulnerability scanning tools like Trivy or Grype in the CI/CD pipeline.. Option A is correct because vulnerability scanning tools like Trivy or Grype are essential for identifying known CVEs in container images before deployment. Integrating these tools into the CI/CD pipeline ensures that only images with an acceptable vulnerability posture are built and pushed to the registry, forming a foundational security gate in the software supply chain.

Answer

Disable admission controllers to reduce latency in pod creation.

Answer

Run all containers as root inside the pod to avoid permission issues.

Question 3

A DevOps team wants to ensure that only signed images from a trusted registry are deployed in the cluster. They plan to use a webhook to intercept pod creation. Which tool is best suited for this task?

Accepted Answer

Kyverno with a verifyImages rule. Kyverno is a Kubernetes-native policy engine that can enforce image signature verification via its `verifyImages` rule. It intercepts pod creation through a dynamic admission webhook, checking that container images are signed with a trusted key (e.g., using Sigstore/Cosign) before the pod is admitted. This directly meets the requirement to only allow signed images from a trusted registry.

Answer

kubectl with --validate flag

Answer

Helm with signed charts

Answer

etcd with encryption at rest

Answer

Prometheus with alerting rules

Question 4

A security audit reveals that a container image running in production contains a critical vulnerability (CVE-2024-1234). The image was built from a base image that had the vulnerability. What is the MOST effective long-term solution to prevent such issues?

Accepted Answer

Rebuild the image using a patched base image and integrate vulnerability scanning into the CI pipeline.. Option D is the most effective long-term solution because it addresses the root cause by rebuilding the image from a patched base image, eliminating the vulnerability at the source. Integrating vulnerability scanning into the CI pipeline ensures that future images are automatically checked for known CVEs before deployment, preventing vulnerable images from reaching production. This aligns with the principle of shifting security left in the software supply chain.

Answer

Use a runtime security tool like Falco to detect exploitation attempts.

Answer

Patch the vulnerability by installing a security update inside the running container.

Answer

Add an admission controller that rejects images with vulnerabilities.

Answer

Switch to a different container runtime that is immune to the vulnerability.

Question 5

An organization uses a private container registry and wants to ensure that only images built from a specific CI/CD pipeline are deployed. Which combination of measures provides the strongest guarantee?

Accepted Answer

Generate signed attestations with in-toto during the CI pipeline and verify them using an admission webhook like Kyverno.. Option E is correct because it implements a complete chain of custody for container images. In-toto generates signed attestations that record every step of the CI/CD pipeline (e.g., source code checkout, build, test), and an admission webhook like Kyverno verifies these attestations before allowing a pod to run. This ensures that only images that passed the exact, attested pipeline are deployed, providing the strongest guarantee against unauthorized or tampered images.

Answer

Implement network policies to restrict egress from pods to the registry.

Answer

Grant registry write access only to the CI system's service account.

Answer

Use a static analysis tool to check the Dockerfile before building.

Answer

Use a unique registry path and restrict access via firewall rules.

Question 6

You are the lead security engineer for a large financial institution. The organization runs a Kubernetes cluster with 500+ microservices. The supply chain security team has implemented the following measures: (1) All images are built from a minimal base image (distroless) and scanned with Trivy before being pushed to a private registry. (2) Images are signed using cosign with a key stored in a hardware security module (HSM). (3) Kyverno policies enforce that only signed images from the private registry can run, and also enforce that containers run as non-root. (4) A binary authorization (binauthz) style admission controller verifies attestations. Recently, a critical vulnerability (CVE-2024-0001) was discovered in a popular open-source library used by several microservices. The library is included as a dependency in the base image. The vulnerability is remotely exploitable and has a CVSS score of 9.8. The security team needs to remediate this quickly. They have already patched the library and updated the base image. What is the BEST course of action to ensure all running pods use the new image?

Accepted Answer

Update the image tag in each Deployment's spec to point to the new patched image, then perform a rolling update. The admission controller will verify signatures and attestations for the new image.. Option A is correct because updating the image tag in each Deployment triggers a rolling update, which creates new pods with the patched image. The admission controller (Kyverno) will verify the cosign signature and binary authorization attestation for the new image, ensuring supply chain security is maintained. This approach is the standard Kubernetes method for deploying image updates while preserving security controls.

Answer

SSH into each node, pull the new image, and use kubectl exec to update the library inside running containers.

Answer

Temporarily disable the admission controller that verifies signatures and then update the image tags.

Answer

Delete all running pods and let the ReplicaSets recreate them from the existing image.

Question 7

A development team uses a custom container image for their application, built from a base image that includes multiple CVEs. The security team requires that no container runs with known critical vulnerabilities. Which approach best ensures that only images with no critical vulnerabilities are deployed in production?

Accepted Answer

Integrate an image scanner (e.g., Trivy) into the CI/CD pipeline to block builds with critical vulnerabilities.. Option C is correct because integrating an image scanner like Trivy into the CI/CD pipeline ensures that any image with critical vulnerabilities is blocked before it is even built or pushed to a registry. This shift-left approach prevents vulnerable images from ever reaching the production environment, aligning with the security team's requirement to deploy only images with no critical vulnerabilities.

Answer

Configure a Kubernetes admission controller (e.g., Kyverno) to reject pods using images with critical vulnerabilities.

Answer

Scan the base image before building the application image.

Answer

Manually review vulnerability reports after the image is deployed.

Question 8

An organization uses a GitOps workflow with Argo CD to deploy applications to Kubernetes. The security team wants to ensure that container images are immutable and signed. They currently use a private container registry (Harbor) with vulnerability scanning and Cosign for signing. Which combination of controls best enforces that only signed and scanned images are deployed?

Accepted Answer

Enable Harbor's content trust feature to reject unsigned images, and use a Kyverno admission rule to verify Cosign signatures at deploy time.. Option D is correct because it enforces a two-layer defense: Harbor's content trust rejects unsigned images at the registry level, and a Kyverno admission rule verifies Cosign signatures at deploy time. This ensures that even if an unsigned image bypasses the registry, it will be blocked by Kubernetes admission control, providing defense in depth for supply chain security.

Answer

Configure Argo CD to verify Cosign signatures before syncing the application.

Answer

Use imagePullSecrets in Kubernetes to ensure only Harbor images are used.

Answer

Add a Cosign verification step in the CI pipeline before pushing images to Harbor, and rely on that guarantee.

Question 9

You are auditing a cluster's supply chain security. You find that many pods are running images from public registries without any pinning or verification. Which TWO actions would most effectively reduce the risk of pulling malicious images?

Accepted Answer

Configure all deployments to use image digests instead of tags.. Option A is correct because using image digests (e.g., `nginx@sha256:abc123...`) pins the image to an immutable content hash, ensuring that the exact same image is pulled every time, even if the tag is updated to a malicious version. This prevents tag-mutation attacks where an attacker replaces a benign image tag with a compromised one. Digests are verified by the container runtime (containerd) against the registry's manifest, providing cryptographic assurance of image integrity.

Answer

Implement RBAC to restrict which users can create pods.

Answer

Enforce PodSecurityStandard baseline or restricted to block privileged containers.

Answer

Apply a network policy that blocks egress traffic to public registries.

Question 10

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?

Accepted Answer

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.. Option C is correct because 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.

Answer

Enforce a PodSecurityStandard that restricts containers from running with root privileges.

Answer

Apply a Kubernetes NetworkPolicy that blocks egress traffic from nodes to Docker Hub.

Answer

Deploy an admission webhook (e.g., OPA/Gatekeeper) that denies pods whose image registry is not the internal Harbor.