CKS Minimize Microservice Vulnerabilities — 10 Questions

Question 1

During a security audit, a team discovers that their microservice application, deployed on Kubernetes, is vulnerable to container breakout attacks. The containers run as root and have many Linux capabilities. Which set of Pod Security Standards (PSS) enforcement modes and policies would best mitigate this risk?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use 'restricted' PSS with Enforce mode. The 'restricted' Pod Security Standard with 'Enforce' mode is the correct choice because it mandates the most stringent security controls, including dropping all Linux capabilities and preventing containers from running as root. This directly mitigates container breakout attacks by eliminating the excessive privileges that enable such exploits. 'Enforce' mode actively blocks non-compliant pods, ensuring the policy is applied without relying on user awareness or audit logs.

Answer

Use 'privileged' PSS with Warn mode

Answer

Use 'baseline' PSS with Audit mode

Answer

Use 'baseline' PSS with Enforce mode

Question 2

A DevOps engineer wants to ensure that all microservice containers run with a read-only root filesystem to prevent unauthorized writes. What is the simplest way to enforce this at the Pod level?

Accepted Answer

Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec. Setting `securityContext.readOnlyRootFilesystem: true` in the Pod spec directly enforces that the container's root filesystem is read-only, preventing any unauthorized writes to the root filesystem. This is the simplest and most direct way to achieve the requirement at the Pod level, as it applies to all containers in the Pod unless overridden at the container level.

Answer

Set `securityContext.runAsNonRoot: true` in the Pod spec

Answer

Mount an emptyDir volume to the container's writable directories

Answer

Set `securityContext.privileged: false` in the Pod spec

Question 3

A security scanner reports that a microservice container image contains a critical vulnerability (CVE-2024-1234) in a system library. The team cannot immediately rebuild the image. What is the most effective temporary mitigation at the Kubernetes level?

Accepted Answer

Apply a custom seccomp profile that blocks the vulnerable syscall. A custom seccomp (secure computing mode) profile can restrict the system calls (syscalls) a container is allowed to make. By blocking the specific vulnerable syscall exploited by CVE-2024-1234, you can prevent the vulnerability from being triggered at runtime without rebuilding the image. This is a temporary, Kubernetes-native mitigation that directly addresses the attack vector at the syscall level.

Answer

Apply a NetworkPolicy to block egress traffic from the Pod

Answer

Apply an AppArmor profile to the Pod

Answer

Use a PodSecurityPolicy to drop all capabilities

Question 4

A microservice container needs to perform DNS lookups using TCP rather than UDP. Which Kubernetes security context setting should be configured to allow this?

Accepted Answer

Add `NET_RAW` capability. TCP DNS lookups use standard TCP sockets, not raw sockets. These are permitted by the default syscall policy, and no additional Linux capability is required. All listed capabilities are unnecessary, as the container already has the ability to create TCP sockets.

Answer

Add `DAC_OVERRIDE` capability

Answer

Add `NET_ADMIN` capability

Answer

Add `NET_BIND_SERVICE` capability

Question 5

Which TWO of the following are effective measures to minimize the impact of a compromised microservice container in a Kubernetes cluster? (Choose two.)

Accepted Answer

Set resource limits (CPU/memory) on the container. Setting resource limits (CPU/memory) on a container is correct because it prevents a compromised microservice from consuming excessive cluster resources, which could lead to a denial-of-service (DoS) attack against other workloads. By enforcing limits via the container's cgroup constraints, the kernel throttles or OOM-kills the container if it exceeds its allocated resources, containing the blast radius of the compromise.

Answer

Set the container's root filesystem as read-only

Answer

Run the container as root to simplify debugging

Answer

Use hostNetwork: true to share the host's network namespace

Question 6

Which THREE of the following practices help protect microservice applications against supply chain attacks? (Choose three.)

Accepted Answer

Use minimal base images (e.g., distroless or scratch) to reduce attack surface. Using minimal base images like distroless or scratch significantly reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could contain vulnerabilities. This aligns with the principle of least functionality, as fewer components mean fewer potential entry points for an attacker to exploit in a supply chain attack.

Answer

Use images from any public registry for flexibility

Answer

Always use the latest tag to get the most recent patches

Question 7

Given the following PodSecurityPolicy (PSP) snippet, which statement about the allowed containers is correct?

Accepted Answer

Containers cannot add any Linux capabilities. The PodSecurityPolicy snippet does not include `allowedCapabilities` or sets it to an empty list, and the `defaultAddCapabilities` is not specified, meaning no Linux capabilities are added by default. Additionally, the `requiredDropCapabilities` field is not present, but the absence of any allowed capabilities effectively prevents containers from adding any Linux capabilities beyond the default set, which is restricted by the PSP's `allowedCapabilities: []` or lack thereof. This enforces a strict security posture where containers cannot gain extra privileges via capabilities.

Answer

Containers can run in privileged mode

Answer

Containers cannot use ConfigMap volumes

Answer

Containers must run as the root user

Question 8

A security engineer runs the following command to inspect a container's security context. What vulnerability does this configuration expose?

Accepted Answer

The container has all capabilities enabled, which is a security risk. The command `docker run --privileged` or a similar configuration that grants all capabilities (e.g., `--cap-add=ALL`) removes all kernel-level isolation, giving the container full access to the host's kernel capabilities. This means the container can perform privileged operations like loading kernel modules, modifying network settings, and accessing raw devices, which directly violates the principle of least privilege and exposes the host to container breakout attacks.

Answer

The container is running without any capabilities

Answer

The container has dropped all capabilities except NET_BIND_SERVICE

Answer

The container has default Docker capabilities, which is secure

Question 9

You are asked to secure a set of microservices running in a Kubernetes cluster. Which TWO of the following practices help minimize vulnerabilities in microservices?

Accepted Answer

Ensure containers run with a non-root user.. Running containers with a non-root user (via the `securityContext.runAsNonRoot: true` field or a specific `runAsUser` directive) prevents privilege escalation and limits the blast radius of a container compromise. This aligns with the principle of least privilege, a core mitigation against container breakout attacks in Kubernetes.

Answer

Manually inject sidecar proxies into every pod to enforce mTLS.

Answer

Run containers in privileged mode to allow them to perform necessary system calls.

Answer

Store secrets directly in container images for easy access.

Question 10

You are a platform engineer at a financial services company. The production cluster runs a set of microservices that handle sensitive customer data. The cluster has been configured with Pod Security Standards (PSS) enforced via OPA/Gatekeeper. Recently, the security team identified that a new deployment of the `payment-processing` microservice is running with the `seccomp` profile set to `Unconfined`. This violates the company policy that requires all containers to use a runtime default seccomp profile. The deployment YAML does not explicitly set any security context for seccomp. The cluster's nodes are running containerd 1.6 with default seccomp profile enabled. The OPA constraint template checks that `securityContext.seccompProfile.type` is set to `RuntimeDefault` or `Localhost`. However, the deployment passes the OPA validation. What is the most likely reason the deployment is not being rejected by OPA, and how should you fix it?

Accepted Answer

The OPA constraint only checks pod-level `securityContext`, but the deployment uses container-level settings.. The OPA constraint template checks `securityContext.seccompProfile.type` at the pod level, but the deployment does not set any security context at the pod level. The seccomp profile is only set at the container level (or defaults to `Unconfined` by the runtime), and the OPA constraint does not inspect container-level `securityContext`. This mismatch allows the deployment to pass validation even though the container is running with an unconfined seccomp profile.

Answer

The seccomp profile must be set via an admission controller, not OPA.

Answer

OPA/Gatekeeper is not properly installed or the constraint is not active.

Answer

The cluster's nodes do not support seccomp, so the profile is ignored.