Skip to content

Kubelet: KCSA practice questions

The kubelet is the primary node agent that runs on every node. It registers the node with the API server and works in terms of PodSpecs: it takes the PodSpecs assigned to its node, primarily from the API server, and ensures that the containers they describe are running and healthy.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Kubelet covers in KCSA

The kubelet is the primary node agent that runs on every node. It registers the node with the API server and works in terms of PodSpecs: it takes the PodSpecs assigned to its node, primarily from the API server, and ensures that the containers they describe are running and healthy. Because it can start containers, read logs and execute commands on its node, the kubelet's own API is one of the most sensitive endpoints in a cluster.

The kubelet serves an HTTPS endpoint, and its defaults are permissive. --anonymous-auth defaults to true, so a request that no other authenticator rejects is treated as system:anonymous in group system:unauthenticated; setting it to false makes such requests fail with 401 Unauthorized. Client certificates are verified against the CA bundle in --client-ca-file, and the API server presents its own client certificate through --kubelet-client-certificate and --kubelet-client-key. With --authentication-token-webhook the kubelet sends bearer tokens to the API server's TokenReview API.

Authorization defaults to AlwaysAllow, which allows every authenticated request, anonymous ones included. --authorization-mode=Webhook makes the kubelet ask the API server through a SubjectAccessReview whether each request is allowed, which brings kubelet access under RBAC. Request paths map to subresources of nodes: /stats to stats, /metrics to metrics, /logs to log, and everything else to proxy. The documentation warns that nodes/proxy grants access to every kubelet API, including those that execute commands in containers, and that even get on it is not read-only. The legacy read-only port, 10255 by default, serves without authentication or authorization and is disabled by setting it to 0. Most of these flags are deprecated in favor of the KubeletConfiguration file passed with --config, which is where they belong in practice.

On the API side, the NodeRestriction admission plugin limits a kubelet's credentials to its own Node object and the Pods bound to it, so stolen kubelet credentials cannot be used to modify the rest of the cluster.

Container lifecycle on the node is also the kubelet's job. A Pod's restartPolicy is Always by default, with OnFailure and Never as alternatives. When containers exit, the kubelet restarts them with an exponential back-off of 10s, 20s, 40s and so on, capped at 300 seconds, and resets the timer after a container has run for 10 minutes without problems; CrashLoopBackOff is the status shown while that back-off is in effect. Running out of memory or CPU is one listed cause of a crash loop.

Node maintenance uses the scheduler's view of the node. kubectl drain safely evicts the Pods on a node, lets their containers terminate gracefully and respects PodDisruptionBudgets, refusing evictions that would drop healthy replicas below a budget; DaemonSet Pods need --ignore-daemonsets because their controller would recreate them on the same node. After maintenance, kubectl uncordon lets the scheduler place new Pods on the node again. Log verbosity is set with -v.

Key points

  • Kubelet defaults are anonymous-auth true and authorization-mode AlwaysAllow; harden to false and Webhook.
  • Webhook authorization sends a SubjectAccessReview to the API server for every kubelet request.
  • nodes/proxy grants all kubelet APIs, including exec into containers, even with only the get verb.
  • The read-only port (default 10255) has no authentication and is disabled by setting it to 0.
  • restartPolicy defaults to Always; restart back-off is capped at 300 seconds.

Three sample questions

10 KCSA questions on Kubelet, 10 with explanations. How practice works

Question 1

What is the recommended method to restrict access to the Kubernetes kubelet API securely?
  1. A.Disable the kubelet service entirely
  2. B.Configure kubelet with '--authorization-mode=Webhook' and '--authentication-token-webhook=true' flags
  3. C.Remove the kubelet binary from all nodes
  4. D.Access kubelet only via SSH tunnels
  5. E.Set '--allow-privileged=false' to restrict privileged containers

Correct answer: B

The kubelet API should be secured by enabling authentication and authorization mechanisms. Using the '--authorization-mode=Webhook' flag enables authorization via an external webhook, typically the API server, while '--authentication-token-webhook=true' enables token-based authentication against the API server. This combination ensures that only authenticated and authorized requests can access the kubelet API. Disabling the kubelet or removing it is impractical as it is essential for node management. Accessing kubelet only via SSH does not inherently secure the API itself. Setting '--allow-privileged=false' restricts privileged containers but does not control API access.

Sources: Kubernetes Official Documentation - Kubelet Authentication and Authorization, CNCF Kubernetes Security Best Practices

Question 2

Which of the following actions can improve the security of the Kubernetes kubelet? (Select all that apply)

Select all that apply.

  1. A.Enable authentication and authorization on the kubelet API
  2. B.Disable anonymous access to the kubelet
  3. C.Expose the kubelet read-only port to all network interfaces
  4. D.Use TLS certificates for kubelet communication
  5. E.Run the kubelet process in privileged mode

Correct answers: A, B, D

Improving kubelet security involves enabling authentication and authorization to ensure only authorized users can access the API, disabling anonymous access to prevent unauthenticated requests, and using TLS certificates to encrypt communication between components. Exposing the read-only port publicly increases attack surface and is discouraged. Running kubelet in privileged mode is not a security best practice and can increase risk.

Sources: Kubernetes Official Documentation - Securing the Kubelet, CNCF Kubernetes Security Best Practices

Question 3

What is the effect of disabling anonymous authentication on the kubelet?
  1. A.Increased security by requiring authentication
  2. B.Nodes cannot join the cluster
  3. C.Pods fail to start
  4. D.kube-proxy stops working
  5. E.No effect; kubelet does not support anonymous access

Correct answer: A

Disabling anonymous authentication on the kubelet enhances security by ensuring that only authenticated requests are accepted. This prevents unauthorized access and reduces the risk of attacks.

Sources: Kubernetes Security Best Practices, Kubelet Documentation

Practice this topic

Focus mode keeps every question on Kubelet until you leave it. 10 free guest answers, then a free account; no credit card.

Or open KCSA practice across all topics.

Sources

The explanation above was checked against these official documents.