CKS System Hardening Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  capabilities.add

  Why this is correct

  The `capabilities.add` field in a container's securityContext is the precise mechanism for granting individual Linux capabilities, such as NET_ADMIN or SYS_TIME, to a specific container without affecting the host or other containers. By explicitly adding only the required capabilities, the container runs with the least privilege necessary, adhering to the principle of least privilege. This field accepts a list of capability names, which are then unioned with the default capability set of the container runtime.

• ✗

  privileged: true

  Why it's wrong here

  Setting `privileged: true` runs the container with all capabilities and disables all security features enforced by the container runtime, effectively giving the container near-host-level access. While this might technically satisfy the requirement of adding capabilities, it is far too broad and insecure because it grants every possible capability and lifts restrictions like seccomp and AppArmor, which is almost never appropriate for a single specific capability. This approach is the anti-pattern of least privilege and is generally reserved for special system-level containers that absolutely need full host access.

• ✗

  allowPrivilegeEscalation: true

  Why it's wrong here

  `allowPrivilegeEscalation: true` controls whether a process can gain more privileges than its parent, typically through setuid binaries or file capabilities, but it does not itself add any capabilities to the container. This boolean flag, when true, permits the container's processes to escalate privileges, but it does not define which capabilities are available—that is the job of the capabilities field. Therefore, this setting alone cannot satisfy the requirement of adding a specific capability, as it merely removes a safety barrier without granting any concrete Linux capability.

• ✗

  capabilities.drop

  Why it's wrong here

  The `capabilities.drop` field is the inverse of `capabilities.add`—it removes capabilities from the container's effective, permitted, and inheritable sets. While dropping capabilities is a recommended security hardening practice, it cannot add capabilities that the container needs. If an administrator needs to grant a specific capability, they must use `capabilities.add`; using `capabilities.drop` would only take capabilities away, potentially causing the container to fail if it requires elevated privileges that were already present in the default set.

Go deeper

Related to this question