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.

• ✓

  Enable the NodeRestriction admission controller

  Why this is correct

  The NodeRestriction admission controller enforces that a kubelet may only modify the Node object it is assigned to, and cannot alter sensitive labels such as kubernetes.io/role or any label with a node.kubernetes.io/ prefix, nor request the node.k8s.io/v1 Node API for other nodes. This directly reduces the attack surface of a compromised worker node by preventing label-based privilege escalation or denial-of-service via node object corruption, working in tandem with Node authorization to enforce the principle of least privilege for node identity.

• ✗

  Set --anonymous-auth=true to allow all users

  Why it's wrong here

  Setting --anonymous-auth=true makes the kube-apiserver accept unauthenticated requests, attributing them to the synthetic system:anonymous user. While RBAC might restrict this user, any unauthenticated attacker who can reach the API server endpoint (e.g., via a misconfigured NetworkPolicy, a compromised pod, or a public ingress) gains the ability to enumerate endpoints, read resources if RBAC allows, or potentially exploit additional misconfigurations. This flag should be false in production, forcing every request to carry valid credentials, otherwise authentication becomes a mere formality and the cluster's security boundary collapses.

• ✗

  Enable audit logging to detect unauthorized attempts

  Why it's wrong here

  Audit logging is a detective control that records a chronological trail of API requests, including who made them, what they accessed, and the outcome. It does not intercept or block malicious actions at execution time; if an attacker has already passed authentication and authorization, they can still perform their actions before any log-based alert triggers. Hardening measures must be preventive, such as NodeRestriction for limiting node privileges or client TLS certificates for establishing identity, while audit logs serve only for post-incident analysis and compliance, not as a barrier against the initial threat.

• ✗

  Disable all authentication mechanisms and rely on network policies

  Why it's wrong here

  Disabling all authentication mechanisms and relying solely on network policies fundamentally misunderstands the threat model: network policies filter pod-to-pod and pod-to-service traffic at the CNI layer, but they do not police who can issue HTTP requests to the kube-apiserver, which is a workload itself often exposed on a cluster-facing port. Without authentication, every request to the API server is effectively anonymous, so any process with network access—including a compromised pod in a different namespace or a rogue container on a host—can call admin endpoints. Network policies also cannot distinguish between legitimate and malicious API verbs, making this an unworkable substitute for identity-based security.

• ✓

  Configure the API server to use TLS certificates for client authentication

  Why this is correct

  Configuring the API server with --client-ca-file enables mutual TLS (mTLS), which requires every client to present a certificate signed by a trusted CA. This provides cryptographic, non-repudiable identity for users, service accounts, and especially kubelets, and is far more resistant to theft than static bearer tokens or passwords. Combined with RBAC, mTLS ensures that even if a network-level attacker can reach the API server, they cannot complete the handshake without a valid certificate, effectively making the API server invisible to unauthorized clients and forming the foundational authenticity layer of all in-cluster communication.

Go deeper

Related to this question