CKS Cluster Hardening Practice Question
You are the security engineer for a multi-tenant Kubernetes cluster. The cluster uses kubeadm and runs Kubernetes v1.24. Each tenant has a dedicated namespace. A new tenant, 'acme-corp', requires that all pods in their namespace run with a read-only root filesystem and must not be able to escalate privileges. They also need to run a legacy container that must listen on a port below 1024. The cluster currently uses PodSecurityPolicy (PSP) but is planning to migrate to Pod Security Admission (PSA). The legacy container needs to run as non-root with the NET_BIND_SERVICE capability to bind to port 80. You need to configure security policies for the 'acme-corp' namespace without affecting other tenants. Which approach best meets these requirements while following Kubernetes best practices?
⚠ Common exam trap
It's easy for candidates to choose Pod Security Admission (PSA) because it is the newer, recommended replacement for PSP, but PSA lacks the granularity to enforce readOnlyRootFilesystem or restrict capabilities to a single capability like NET_BIND_SERVICE, leading to an incorrect choice like Option A or C.
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
✓
Use OPA/Gatekeeper to create a ConstraintTemplate that requires readOnlyRootFilesystem and allows only NET_BIND_SERVICE capability, then apply it to acme-corp namespace
OPA/Gatekeeper allows fine-grained, namespace-scoped policy enforcement that can require readOnlyRootFilesystem and restrict capabilities to only NET_BIND_SERVICE, meeting all requirements without affecting other tenants. Pod Security Admission (PSA) does not support custom capability restrictions or readOnlyRootFilesystem enforcement natively, and PSP is deprecated in Kubernetes v1.24 and being removed, making it unsuitable for new configurations. Gatekeeper’s ConstraintTemplate provides the flexibility to enforce these specific security contexts while following best practices for policy-as-code.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable Pod Security Admission with the 'baseline' policy in enforce mode for acme-corp namespace, and add a mutating webhook to set readOnlyRootFilesystem
Why it's wrong here
Pod Security Admission (PSA) with the 'baseline' policy in enforce mode restricts a limited set of dangerous features but does not enforce readOnlyRootFilesystem, and it also does not limit allowed capabilities to only NET_BIND_SERVICE — it merely blocks a handful of dangerous capabilities. Adding a mutating webhook to inject readOnlyRootFilesystem would mean maintaining a separate cluster-critical component, introducing possible bypasses or ordering issues with PSA, and still leaves the capability set too broad. This approach is complex and does not fully express the required security controls, making it inferior to a policy engine like Gatekeeper.
- ✓
Use OPA/Gatekeeper to create a ConstraintTemplate that requires readOnlyRootFilesystem and allows only NET_BIND_SERVICE capability, then apply it to acme-corp namespace
Why this is correct
OPA/Gatekeeper is the appropriate choice because it provides a flexible, declarative policy engine that can enforce arbitrary constraints via ConstraintTemplates. A dedicated template can validate that every pod in acme-corp sets securityContext.readOnlyRootFilesystem to true and that any added Linux capabilities are limited to exactly NET_BIND_SERVICE. This approach is more precise than Pod Security Standards, is actively maintained, and can be scoped to a namespace with a Constraint resource, while also supporting dry-run and audit modes for safe rollout.
- ✗
Use Pod Security Admission with the 'privileged' policy and rely on the legacy container's securityContext
Why it's wrong here
Pod Security Admission with the 'privileged' policy is the most permissive profile — it explicitly permits privileged containers, host namespaces, host networking, and any Linux capabilities, so it does not provide any baseline tenant isolation. Relying on individual container securityContext settings is unenforceable at the admission level; a developer could omit those settings and the pod would run with the full privileges of the policy. This setup essentially delegates security to human error and is the opposite of the least-privilege requirements in the question.
- ✗
Create a new PSP that allows NET_BIND_SERVICE and requires readOnlyRootFilesystem, then bind it to the acme-corp namespace via RoleBinding
Why it's wrong here
Creating a new PodSecurityPolicy is not the best approach because PSPs are deprecated in Kubernetes v1.24 and are scheduled for removal in v1.25. Relying on a deprecated feature for a new tenant's configuration, especially when the cluster plans to migrate to Pod Security Admission, contradicts Kubernetes best practices. PSPs were previously the standard mechanism for enforcing granular pod security constraints, such as `readOnlyRootFilesystem` and specific capabilities like `NET_BIND_SERVICE`, and could be effectively scoped to namespaces via RoleBindings in older Kubernetes versions.
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.