Which TWO of the following are effective measures to minimize the impact of a compromised microservice container in a Kubernetes cluster? (Choose two.)
Trap 1: Set the container's root filesystem as read-only
Setting the container's root filesystem to read-only (readOnlyRootFilesystem: true) does prevent an attacker from writing malware or tampering with system binaries inside the container image, which is a strong integrity control. However, it does nothing to restrict the container's ability to communicate with other pods, reach external services, or abuse legitimate tools already present inside the image. An attacker can still perform lateral movement, exfiltrate data, or interact with services across namespaces using existing binaries and outbound connections, so this measure alone does not confine a compromise's movement.
Trap 2: Run the container as root to simplify debugging
Running the container as root (or with a privileged user) violates the principle of least privilege and dramatically increases the risk of a container breakout. Even with a non-privileged container, a kernel exploit that lets an unprivileged root process (e.g., via CAP_SYS_ADMIN or chroot escapes) gain host root access becomes far more damaging if the attacker already controls a root process inside the container. Root also gives the process full freedom to read sensitive files, install setuid binaries, and interact with host devices if security contexts are not restricted, thereby enlarging the blast radius in ways that resource limits or network policies cannot contain.
Trap 3: Use hostNetwork: true to share the host's network namespace
Setting hostNetwork: true grants the container the exact same network namespace as the host machine, meaning every socket opened by the compromised container appears as a host process and can bind to any host interface. This bypasses the pod-level network isolation that Kubernetes normally provides, allowing the attacker to sniff host network traffic, connect to internal services on the host, and potentially interfere with other containers or the kubelet. It also makes NetworkPolicy ineffective because pod egress/ingress rules are typically not enforced for pods using the host network namespace, greatly expanding the attack surface.
- A
Set resource limits (CPU/memory) on the container
Setting CPU and memory limits on a container (via Kubernetes resources.limits) enforces cgroup quotas that prevent a compromised process from consuming all node compute, memory, or of triggering an OOM-kill cascade that starves neighboring workloads. Without these limits, a small exploit such as a fork bomb or memory leak in a single pod can degrade or crash the entire node, turning a contained compromise into a cluster-wide denial of service. Resource limits narrow the blast radius of a resource-based attack and are a fundamental building block for multi-tenant cluster hardening.
- B
Set the container's root filesystem as read-only
Why it fails: Setting the container's root filesystem to read-only (readOnlyRootFilesystem: true) does prevent an attacker from writing malware or tampering with system binaries inside the container image, which is a strong integrity control. However, it does nothing to restrict the container's ability to communicate with other pods, reach external services, or abuse legitimate tools already present inside the image. An attacker can still perform lateral movement, exfiltrate data, or interact with services across namespaces using existing binaries and outbound connections, so this measure alone does not confine a compromise's movement.
- C
Apply a NetworkPolicy that restricts egress traffic to only necessary services
Applying a NetworkPolicy with a restrictive egress rule forces all outbound traffic from the pod to pass through a firewall-like filter that only allows connections to explicitly permitted DNS, API, or business services. This directly limits the blast radius of a compromised container by cutting off communication to other pods, the Kubernetes API server, or the internet, making lateral movement and data exfiltration significantly harder. It is a network-level isolation control that complements resource limits and filesystem hardening by preventing the compromised process from reaching other cluster workloads.
- D
Run the container as root to simplify debugging
Why it fails: Running the container as root (or with a privileged user) violates the principle of least privilege and dramatically increases the risk of a container breakout. Even with a non-privileged container, a kernel exploit that lets an unprivileged root process (e.g., via CAP_SYS_ADMIN or chroot escapes) gain host root access becomes far more damaging if the attacker already controls a root process inside the container. Root also gives the process full freedom to read sensitive files, install setuid binaries, and interact with host devices if security contexts are not restricted, thereby enlarging the blast radius in ways that resource limits or network policies cannot contain.
- E
Use hostNetwork: true to share the host's network namespace
Why it fails: Setting hostNetwork: true grants the container the exact same network namespace as the host machine, meaning every socket opened by the compromised container appears as a host process and can bind to any host interface. This bypasses the pod-level network isolation that Kubernetes normally provides, allowing the attacker to sniff host network traffic, connect to internal services on the host, and potentially interfere with other containers or the kubelet. It also makes NetworkPolicy ineffective because pod egress/ingress rules are typically not enforced for pods using the host network namespace, greatly expanding the attack surface.