Kubernetes Node Hardening Best Practices: Non-Root, Drop Caps, Read-Only FS

• ✓ A.Minimize host access from containers (e.g., disable hostPID, hostNetwork)
• ✓ B.Use minimal base container images
• ✓ C.Disable unnecessary system services on nodes
• D.Expose the host network to containers for better performance
• E.Run containers as root to simplify permissions

Why A: Option A is correct because disabling hostPID and hostNetwork prevents containers from accessing the host's process namespace and network stack, which would otherwise allow privilege escalation or network sniffing. This aligns with the principle of least privilege and reduces the node's attack surface by isolating container workloads from the host OS.

• ✓ A.Use read-only root filesystems for containers where possible
• B.Allow privileged containers for debugging
• ✓ C.Disable unnecessary system services on nodes
• D.Run containers as root to simplify management
• ✓ E.Minimize host access from containers (avoid hostPID, hostNetwork, hostIPC)

Why A: Option A is correct because using a read-only root filesystem for containers (e.g., setting `readOnlyRootFilesystem: true` in the container's security context) prevents attackers from writing malicious binaries or modifying system files inside the container, even if they gain code execution. This reduces the attack surface by limiting the container's ability to persist changes or escalate privileges through file system manipulation.

• A.Using read-only root filesystems
• B.Running containers as non-root
• ✓ C.Running containers with privileged: true
• D.Disabling unnecessary system services on nodes

Why C: Option C is correct because setting `privileged: true` in a container's security context grants it elevated capabilities equivalent to running as root on the host, including access to all kernel namespaces and devices. This directly increases the attack surface by allowing the container to perform host-level operations, such as loading kernel modules or modifying network settings, which violates the principle of least privilege. The CKS exam emphasizes that privileged containers should be avoided unless absolutely necessary, and they are never a recommended method for reducing the attack surface.

• A.Load all kernel modules to support any workload
• ✓ B.Restrict hostNetwork, hostPID, and hostIPC access from containers
• C.Enable SSH access for all users for troubleshooting
• ✓ D.Disable unnecessary system services on the node
• E.Allow containers to run as root

Why B: Restricting hostNetwork, hostPID, and hostIPC access from containers is a valid way to reduce the attack surface of a Kubernetes node because it prevents containers from breaking out of their namespace isolation. When a container uses hostNetwork, it shares the node's network stack, potentially allowing it to sniff traffic or bind to privileged ports. Similarly, hostPID and hostIPC grant access to the host's process table and inter-process communication mechanisms, which can be leveraged for privilege escalation or information disclosure. By default, these should be disabled unless absolutely necessary, as they directly expose host-level resources to the container.

• ✓ A.Disable unnecessary system services on nodes
• ✓ B.Minimize host access from containers (avoid hostPID, hostNetwork, hostIPC)
• C.Open all ports on nodes to allow easy debugging
• D.Run all containers as root user
• ✓ E.Apply Pod Security Standards to enforce least privilege

Why A: Option A is correct because disabling unnecessary system services on Kubernetes nodes reduces the number of running processes and open ports that could be exploited by an attacker. Services like telnet, rsh, or unused SNMP daemons provide additional attack vectors. This aligns with the principle of minimalism in system hardening, as recommended by the CIS Kubernetes Benchmark.