hardMultiple Choice
CKS Practice Question: A cluster has been hardened by setting…
A cluster has been hardened by setting --anonymous-auth=false and enabling RBAC. However, kube-bench still reports a failure for the kubelet check 'Ensure that the --anonymous-auth argument is set to false'. What could be the reason?
⚠ Common exam trap
Watch out — candidates often assume command-line flags always override the kubelet configuration file, but in reality the configuration file takes precedence for kubelet settings, so both must be set consistently.
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
✓
The kubelet configuration file does not set --anonymous-auth=false
The kubelet can have its authentication settings configured either via command-line arguments or via a KubeletConfiguration file. If the kubelet configuration file does not explicitly set `authentication.anonymous.enabled` to `false`, the kubelet may still allow anonymous access even if the `--anonymous-auth=false` argument is passed on the command line, because the configuration file takes precedence over command-line flags. kube-bench checks the effective configuration, so if the file overrides the flag, the check fails.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The kubelet configuration file does not set --anonymous-auth=false
Why this is correct
The kubelet has its own HTTP server on port 10250 with independent authentication settings, and its configuration file (e.g., /var/lib/kubelet/config.yaml) must explicitly disable anonymous access via the authentication.anonymous.enabled field or the --anonymous-auth=false flag. Kube-bench checks this setting separately from the API server, because simply setting anonymous-auth=false on the API server does not propagate to the kubelet. When the kubelet configuration lacks this explicit disabling, anonymous requests can still reach kubelet endpoints such as /pods, making this the correct root cause for the reported finding.
- ✗
The API server is running with --authorization-mode=AlwaysAllow
Why it's wrong here
This option describes the API server's authorization mode, not the kubelet's authentication behavior. The kubelet does not consult the API server's --authorization-mode when deciding whether to accept anonymous requests; that decision is made locally by the kubelet's own anonymous-auth setting. Even if the API server were correctly using RBAC or ABAC, the kubelet could still allow anonymous access if its own anonymous-auth is not disabled. Thus, while AlwaysAllow would be a critical API server misconfiguration, it is not the cause of the kubelet anonymous-auth finding.
- ✗
The kubelet is using a self-signed certificate
Why it's wrong here
A self-signed certificate affects TLS trust and how clients verify the kubelet's identity, but it has no bearing on whether the kubelet accepts unauthenticated anonymous requests. Anonymous authentication means requests are processed without any client certificate or token; this is governed entirely by the kubelet's authentication settings, not by the serving certificate type. Even with a valid CA-signed certificate, the kubelet will still honor anonymous requests if --anonymous-auth=false is not set. Therefore, the self-signed cert is a TLS concern, not an anonymous-auth concern.
- ✗
The NodeRestriction admission plugin is not enabled
Why it's wrong here
The NodeRestriction admission plugin limits what authenticated Node objects can modify in the API server, such as labels or certain resources, and it applies to requests that already passed authentication. It does not control the kubelet's standalone HTTP endpoints or whether anonymous requests are accepted at the kubelet port. Anonymous requests to the kubelet never reach admission control because that layer only applies to API server requests. Therefore, missing NodeRestriction is an unrelated API server defense-in-depth issue and cannot explain the kubelet anonymous-auth misconfiguration.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.