hardMultiple Choice
CKS Tasked with securing a Kubernetes cluster Practice Question
You are tasked with securing a Kubernetes cluster. You want to ensure that the kubelet only serves APIs that are explicitly allowed and that it does not allow anonymous requests. Which kubelet configuration flags should you set?
⚠ Common exam trap
Test-takers frequently confuse kubelet authorization modes with API server authorization modes, mistakenly selecting `RBAC` (Option A) which is not a valid kubelet flag, while overlooking that `Webhook` is the correct mode to enforce RBAC-like policies on the kubelet.
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
✓
--anonymous-auth=false and --authorization-mode=Webhook
Setting `--anonymous-auth=false` disables anonymous requests to the kubelet, and `--authorization-mode=Webhook` delegates authorization decisions to an external service (e.g., the API server), allowing fine-grained control over which APIs the kubelet serves. This combination ensures that only authenticated, authorized requests are processed, aligning with the principle of least privilege.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
--anonymous-auth=false and --authorization-mode=RBAC
Why it's wrong here
The kubelet's --authorization-mode flag accepts only AlwaysAllow or Webhook; RBAC is a valid mode for the API server, not for the kubelet. Setting --authorization-mode=RBAC will cause the kubelet to fail validation, and even if it were accepted, the kubelet has no native RBAC enforcement engine and cannot evaluate RoleBindings or ClusterRoles. Instead, it must delegate authorization decisions to the API server through SubjectAccessReview calls, which is exactly what the Webhook mode does. Thus, this combination is not a secure or functional configuration.
- ✗
--anonymous-auth=true and --authorization-mode=ABAC
Why it's wrong here
ABAC is a deprecated authorization model that was only implemented for the API server, not the kubelet, so this flag combination is invalid from the start. Even conceptually, pairing anonymous authentication with any legacy static policy is dangerous because unauthenticated requests are treated as anonymous users, and ABAC policies are complex attribute strings that are notoriously difficult to audit and maintain. With anonymous auth enabled, an unauthenticated attacker can attempt to fit the ABAC policy's subject attributes, potentially gaining kubelet access. For a secure cluster, you must use Webhook mode and disable anonymous access.
- ✗
--anonymous-auth=false and --authorization-mode=AlwaysAllow
Why it's wrong here
While disabling anonymous authentication is necessary, setting --authorization-mode=AlwaysAllow means the kubelet will authorize every authenticated request without consulting any policy. Any user, service account, or node that possesses a valid credential from the cluster can invoke privileged kubelet actions such as pod exec, log retrieval, or even kernel calls via the runtime, without any RBAC or webhook restriction. This narrows the attack surface only against unauthenticated traffic and leaves the cluster vulnerable to malicious authenticated workloads. The kubelet must use Webhook mode to actually enforce fine-grained authorization.
- ✓
--anonymous-auth=false and --authorization-mode=Webhook
Why this is correct
This is the recommended secure configuration because disabling anonymous auth ensures no unauthenticated request reaches the kubelet's server, while the Webhook mode delegates every authorization decision to the API server's SubjectAccessReview endpoint. The API server evaluates the request against RBAC rules for the kubelet's credentials, meaning a user or service account can only see or control pods they are explicitly allowed to access. This integration also ensures that kubelet authorization is centrally managed and consistent with the rest of cluster policy, rather than relying on a local fallback. The flag combination is the golden standard for production Kubernetes hardening.
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.