CKS Practice Question: Prevent the kubelet from serving anonymous…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  --client-ca-file=/etc/kubernetes/pki/ca.crt

  Why it's wrong here

  The --client-ca-file flag specifies a Certificate Authority used to validate client certificates presented to the kubelet's HTTPS endpoint. While this enables mutual TLS authentication for clients that present a valid certificate signed by that CA, it does not affect the kubelet's handling of unauthenticated requests. When anonymous-auth is still enabled (the default), any request without a valid client certificate is automatically authenticated as user system:anonymous and may still be authorized. Thus, setting this flag alone does not prevent the kubelet from serving to anonymous users; it simply adds an additional authentication method without disabling the anonymous fallback.

• ✗

  --authorization-mode=Webhook

  Why it's wrong here

  The --authorization-mode=Webhook flag configures how the kubelet makes authorization decisions: it sends SubjectAccessReview requests to an external webhook endpoint. However, this flag operates at the authorization layer, not the authentication layer. Before authorization can occur, the request must be authenticated; if anonymous authentication is permitted, a request with no credentials is still authenticated as system:anonymous and then passed to the authorization webhook. Thus, even with Webhook authorization, the kubelet may still serve to anonymous users if the webhook authorizes them. To actually prevent anonymous access, you must disable anonymous authentication with --anonymous-auth=false; merely changing the authorization mode does not address the authentication gap.

• ✓

  --anonymous-auth=false

  Why this is correct

  The --anonymous-auth=false flag disables the kubelet's built-in anonymous authentication policy. When this flag is set to false, requests that do not present verifiable client credentials are rejected with HTTP 401 before any authorization check occurs. This is the direct and intended mechanism to prevent the kubelet from serving to unauthenticated, anonymous clients. Without setting this flag, the kubelet remains vulnerable to unauthenticated access to its health/readiness endpoints, pod listing, and even exec/attach capabilities depending on authorization configuration. Therefore, this is the correct and minimal flag to achieve the administrator's stated goal.

• ✗

  --authentication-token-webhook=true

  Why it's wrong here

  The --authentication-token-webhook=true flag enables the kubelet to authenticate requests by sending a TokenReview to a webhook API, typically to validate service account tokens or other bearer tokens. While this adds a robust token-based authentication method, it does not disable anonymous authentication. If anonymous-auth remains at its default value of true, any request that presents no token or an invalid token will still fall back to the anonymous identity. Thus, enabling token webhook authentication is an enhancement to the authentication stack, not a restriction on anonymous access. To actually block anonymous clients, you must explicitly set --anonymous-auth=false; this flag alone leaves the anonymous path open.