CKS Practice Question 1: kubelet Anonymous Auth Hardening

Certified Kubernetes Security Specialist (CKS) · Test 1 · question 1 of 10

Cluster Setupmedium

A kube-bench run against a worker node reports two failures: *"Ensure that the --anonymous-auth argument is set to false"* and *"Ensure that the --authorization-mode argument is not set to AlwaysAllow"*. The kubelet on this node is started by systemd with a single flag, --config=/var/lib/kubelet/config.yaml, and all other settings come from that file.

You must remediate both findings so that unauthenticated callers of the kubelet API on port 10250 are rejected and every authenticated request is checked against the API server. What should you do?

Show answer and explanation

Answer:

C. In /var/lib/kubelet/config.yaml set authentication.anonymous.enabled: false and authorization.mode: Webhook, then restart the kubelet

Both findings are kubelet settings. When the kubelet is driven by a config file (KubeletConfiguration), the command-line flags --anonymous-auth and --authorization-mode have their equivalents at authentication.anonymous.enabled and authorization.mode. Setting anonymous access to false makes the kubelet answer unauthenticated requests with 401 Unauthorized instead of treating them as the user system:anonymous in group system:unauthenticated. Setting the authorization mode to Webhook makes the kubelet issue a SubjectAccessReview to the API server for every request rather than the default AlwaysAllow, which permits everything. A kubelet restart is required for the config file to be re-read.

Option A changes the wrong component. The API server has its own --anonymous-auth and --authorization-mode flags, and hardening them does nothing for the kubelet's own HTTPS endpoint, which is exactly what kube-bench flagged on the node.

Option B does not work: NetworkPolicy is enforced by the CNI plugin for Pod traffic and does not govern traffic to a process listening on the node's host network, such as the kubelet. It also leaves the insecure configuration in place.

Option D misunderstands where the check happens. While authorization.mode is AlwaysAllow, the kubelet never consults RBAC at all, so removing bindings for system:unauthenticated changes nothing. RBAC only becomes relevant once Webhook authorization is turned on.

Reference: Kubelet authentication/authorization

Practice Test 1 ›

Study guides for CKS

Kubernetes interview questions: scenarios for experiencedScenario-based Kubernetes interview questions for experienced engineers: CrashLoopBackOff, DNS, RBAC, drains and etcd, with the commands and fixes.

How AI Is Changing Software Jobs: Where to PrepareHow AI is changing software jobs: what history shows, the evidence on junior developers, what Klarna learned, new AI roles and five domains to prepare for.

Best cloud security certification in 2026: which one firstCompare the top cloud security certifications for 2026, from AWS Security Specialty, SC-500 and Google PCSE to CKS and CCSP, and the order to take them.

Best Kubernetes certification: CKA vs CKAD vs CKSWhich Kubernetes certification to take first - CKA, CKAD or CKS compared on format, cost, prerequisites and role, plus KCNA and KCSA for beginners.

Kubernetes NetworkPolicy, explained for CKA, CKAD and CKSHow NetworkPolicy isolation works, why policies only add allows, the namespaceSelector AND/OR trap, DNS egress, and what your CNI has to support.