CKS System Hardening Practice Question
A security team is hardening a Kubernetes cluster. They need to ensure that all control plane components run with the least privilege. Which approach should they take?
⚠ Common exam trap
CNCF often tests the distinction between runtime security mechanisms (seccomp, AppArmor) and container-level privilege controls (user ID, read-only filesystem), leading candidates to choose a syscall or MAC profile instead of the direct least-privilege configuration.
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 control plane containers to run as non-root user and with read-only root filesystem
Running control plane containers as a non-root user and with a read-only root filesystem directly enforces the principle of least privilege at the container level. This approach limits the ability of an attacker who compromises a control plane component to escalate privileges or modify critical system files, which is a fundamental hardening requirement for the control plane.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use seccomp profiles to block privilege escalation syscalls
Why it's wrong here
A seccomp profile filters system calls at the kernel boundary, but it does not change the UID/GID that the container process runs with; a root user inside the container simply cannot invoke blacklisted syscalls, yet retains a broad set of permitted root-only operations. Blocking syscalls such as unshare or mount does not satisfy the requirement to run the control plane as a non-root user with a read-only filesystem.
- ✗
Apply AppArmor profiles to all control plane pods
Why it's wrong here
AppArmor confines a specific executable or daemon to an allowed set of files, capabilities, and network operations via an LSM profile, but it leaves the container's user context untouched. The profile is also tied to the host's loaded profiles and must be applied per pod via annotations; it cannot force the control plane process to run as non-root or make its root filesystem read-only.
- ✓
Configure control plane containers to run as non-root user and with read-only root filesystem
Why this is correct
Setting runAsNonRoot: true and an explicit runAsUser (for example, 1000) in the pod security context, along with readOnlyRootFilesystem: true, directly removes root privileges and makes the container's immutable root filesystem fail-closed on any write attempt. This is the most effective hardening for control plane components because it attacks both privilege escalation and tampering of the container's filesystem at the source, rather than filtering specific kernel or program actions.
- ✗
Enable PodSecurityPolicy with 'MustRunAsNonRoot' for control plane namespaces
Why it's wrong here
PodSecurityPolicy is deprecated since Kubernetes 1.21 and removed in 1.25, so it cannot be reliably used on modern versions; the replacement Pod Security Admission does not define a must-run-as-non-root and read-only-filesystem pair. Even if MustRunAsNonRoot were valid, it only validates that the container runs with a non-zero UID, and it does nothing to prevent container processes from modifying the root filesystem.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.