CKS System Hardening Practice Question
A cluster has been compromised due to a container running with privileged escalation. The team wants to prevent any container from gaining new privileges. Which configuration should be applied?
⚠ Common exam trap
CNCF often tests the misconception that dropping all capabilities is sufficient to prevent privilege escalation, but the trap is that capabilities and privilege escalation are separate controls—`allowPrivilegeEscalation: false` is the specific setting to block setuid-based escalation.
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
✓
Set securityContext.allowPrivilegeEscalation: false
Setting `securityContext.allowPrivilegeEscalation: false` directly prevents a container from gaining new privileges beyond those it was initially granted, such as through setuid binaries or the `NO_NEW_PRIVS` flag. This is the exact control needed to block privilege escalation attacks, as it forces the kernel to deny any request for elevated privileges, even if the binary has the setuid bit set.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set securityContext.runAsUser: 1000
Why it's wrong here
Running as a non-root user (e.g., UID 1000) only changes the numeric user ID of the process; it does not modify the kernel's authorization model or disable setuid semantics. A malicious process can still execute a binary with the setuid bit set, such as /usr/bin/sudo or a program with the SUID root flag, which temporarily grants euid=0 and therefore privileges beyond the original user. Additionally, runAsUser does not restrict syscalls like ptrace or mount, nor does it prevent exploiting kernel vulnerabilities to elevate privileges. Thus, while runAsUser is a good hardening step, it does not directly block the privilege escalation channel described in the incident.
- ✗
Set securityContext.readOnlyRootFilesystem: true
Why it's wrong here
Setting readOnlyRootFilesystem: true prevents writes to the root filesystem, making tampering with binaries or configuration files harder, but it does not stop a process from executing privilege-escalating operations. The kernel still allows the process to invoke privileged syscalls (e.g., mount, chroot, or ptrace) because the filesystem restriction is orthogonal to capability checks. An attacker could also write a setuid binary to an emptyDir volume or writable path and execute it, and temporary filesystems like /dev/shm or /tmp remain writable unless explicitly remounted. Therefore, read-only root is a filesystem integrity control, not a privilege-escalation prevention mechanism.
- ✗
Drop all capabilities with securityContext.capabilities.drop: ["ALL"]
Why it's wrong here
Dropping all Linux capabilities with capabilities.drop: ["ALL"] removes the process's permitted and effective capability sets, but it does not disable the setuid mechanism that many binaries rely on. When a process executes a setuid-root binary, the kernel sets the effective UID to 0 and then grants the process the full root capabilities regardless of its previous capability state, because the privilege escalation is based on UID transition, not on existing capabilities. Thus, even a container with no capabilities can gain complete root privileges by running a setuid binary that is present in the image (e.g., /bin/su, mounted host binaries, or a compromised setuid utility). Capability dropping is valuable for reducing the attack surface, but it does not directly block the setuid path.
- ✓
Set securityContext.allowPrivilegeEscalation: false
Why this is correct
Setting allowPrivilegeEscalation: false directly applies the Linux 'no_new_privs' flag to the container process, which prevents the process and its children from ever gaining more privileges than their original execution context, even if a later exec of a setuid-root or capability-enabled binary occurs. This is a kernel-level mechanism that blocks the common privilege-escalation vectors such as SUID binaries, file capabilities, and certain ioctl-based operations. It is the most direct security control among the options because it explicitly targets the privilege-escalation mechanism itself, rather than only constraining the user ID, filesystem, or capabilities. For this compromised container, this setting is necessary to contain the breach and prevent further elevation.
Go deeper
Related to this question
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.