CKS System Hardening Practice Question
You are a security engineer at a company running a Kubernetes cluster in production. The cluster uses containerd as the container runtime and has been configured with Node Authorizer and NodeRestriction admission controller. Recently, a security audit revealed that several pods running as root have been compromised via container escape vulnerabilities. The audit report recommends hardening the nodes to reduce the attack surface. Specifically, you need to ensure that even if an attacker gains root access inside a container, they cannot execute privileged operations on the host node, such as loading kernel modules, modifying host network settings, or accessing host devices. The cluster runs on Ubuntu 20.04 nodes with Linux kernel 5.4. You have access to modify node-level configurations but must minimize performance impact and avoid breaking existing workloads that rely on standard Linux capabilities. Which of the following actions would most effectively mitigate these risks?
⚠ Common exam trap
CNCF often tests the misconception that dropping capabilities alone is sufficient for host-level hardening, but the trap here is that capabilities only restrict privileged operations that require them, while seccomp provides syscall-level filtering that can block escape vectors even when the container runs as root.
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 containerd to use a default seccomp profile that blocks unprivileged user namespaces and restricts kernel modules loading, and apply it to all pods via a mutating admission webhook.
Seccomp (secure computing mode) can filter system calls at the kernel level, and by configuring containerd to use a default seccomp profile that blocks syscalls related to unprivileged user namespaces (e.g., `clone` with `CLONE_NEWUSER`) and kernel module loading (e.g., `init_module`, `finit_module`), you prevent container escapes from performing privileged host operations. This approach is runtime-level, applies globally without modifying pod specs, and minimizes performance impact since seccomp uses a BPF-based filter that adds negligible overhead.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure containerd to use a default seccomp profile that blocks unprivileged user namespaces and restricts kernel modules loading, and apply it to all pods via a mutating admission webhook.
Why this is correct
A default seccomp profile that blocks risky syscalls (e.g., those used for kernel module loading, user namespace creation) effectively prevents many container escapes without breaking most workloads. Applying it via a webhook ensures all pods use it.
- ✗
Enable user namespaces for all containers by setting the 'hostUsers: false' option in the pod spec, which maps container root to a non-root user on the host.
Why it's wrong here
User namespace remapping is a strong security feature but is still in alpha in Kubernetes 1.22 and may not be available in the current cluster version. It also requires runtime support and can cause compatibility issues with host volumes.
- ✗
Remove the CAP_SYS_ADMIN and CAP_NET_ADMIN capabilities from all containers by setting a default PodSecurityPolicy that drops these capabilities.
Why it's wrong here
Dropping CAP_SYS_ADMIN and CAP_NET_ADMIN is a sensible hardening measure, but it only removes two capabilities and leaves many other kernel attack surfaces exposed. Container escapes frequently exploit unprivileged user namespaces, missing seccomp filters, or kernel vulnerabilities that do not require these capabilities. Additionally, PodSecurityPolicy has been deprecated since Kubernetes 1.21 and removed in 1.25, so relying on it is not a forward-looking or comprehensive defense.
- ✗
Enable AppArmor on all nodes and apply a custom profile that denies all mount and network-related system calls.
Why it's wrong here
Denying all mount- and network-related system calls via AppArmor would severely disrupt normal cluster operations, as pods and container runtimes legitimately rely on mount operations and network sockets. AppArmor profiles operate at a higher abstraction level (path and capability mediation) and lack seccomp's fine-grained syscall filtering, so a blanket denial is both overly broad and ineffective at stopping exploit primitives like unprivileged user namespace creation or kernel module loading.
Go deeper
Related to this question
Learn chapter
Cluster Hardening: Resource Quotas and Limit Ranges
Key term
OPA Gatekeeper
OPA Gatekeeper is a Kubernetes admission controller that enforces custom security and compliance policies on resources before they are created or updated in a cluster.
Key term
Seccomp Profiles
Seccomp profiles are security filters that restrict which system calls a containerized application can make to the Linux kernel, reducing the attack surface.
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.