Fix CIS Benchmark Findings on the Kubelet and etcd

Original Prepium guide · Written for Kubernetes v1.35 and checked against the official documentation on 6 October 2026. Use a disposable practice cluster. You will restart a kubelet and edit etcd's static Pod, so use throwaway kubeadm VMs, never a shared cluster.

Lock down the kubelet API, then prove it with a benchmark and curl

Every node's kubelet serves an HTTPS API on port 10250 that can list Pods, read logs and even run commands in containers. Like the API server, it has an authentication step and an authorization step, and both can be left wide open. CIS benchmark tools such as kube-bench flag these settings, and the CKS expects you to fix them in the right file and restart the right component.

client ──→ kubelet :10250
           authentication: x509 client cert │ webhook (TokenReview) │ anonymous → system:anonymous
           authorization:  AlwaysAllow (everything) │ Webhook (SubjectAccessReview to the API server)

1. Find where the kubelet really gets its settings

systemctl cat kubelet
sudo cat /var/lib/kubelet/kubeadm-flags.env
sudo grep -A6 -E '^(authentication|authorization):' /var/lib/kubelet/config.yaml
ps -o args= -C kubelet

On kubeadm nodes the systemd drop-in passes --config=/var/lib/kubelet/config.yaml plus extra flags from kubeadm-flags.env. Command-line flags override the same setting in the config file, so a forgotten --anonymous-auth or --authorization-mode flag beats whatever you write in YAML. Check the running process arguments before you trust the file.

2. Understand the defaults trap

The two ways of configuring the kubelet have different defaults. The flag reference describes anonymous requests as allowed and AlwaysAllow as the default mode, while the KubeletConfiguration file defaults to anonymous disabled, webhook token authentication enabled and mode: Webhook. A hardened config states the values explicitly so nobody has to remember which default applies:

authentication:
  anonymous:
    enabled: false        # unauthenticated callers get 401
  webhook:
    enabled: true         # bearer tokens checked with TokenReview
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt   # kubeadm's cluster CA
authorization:
  mode: Webhook           # each request checked with SubjectAccessReview

After editing, sudo systemctl restart kubelet and watch kubectl get nodes: the node can show NotReady briefly while the kubelet comes back. If it stays NotReady, journalctl -u kubelet usually shows a YAML or field error.

3. Probe the API from outside

NODE_IP=192.0.2.21
curl -sk -o /dev/null -w "%{http_code}\n" https://$NODE_IP:10250/pods

Read the code, not the body. 200 with a Pod list means anonymous callers are authenticated and authorized, the worst case. 403 means anonymous authentication is still on but Webhook authorization refused system:anonymous. 401 means anonymous authentication is off. Note that get on the nodes/proxy subresource is not read-only: it can reach exec endpoints, so do not grant it casually.

4. The same idea for etcd and the benchmark

etcd should accept only clients presenting a certificate signed by its trusted CA. That is the --client-cert-auth=true flag together with --trusted-ca-file, set in the command of /etc/kubernetes/manifests/etcd.yaml on kubeadm clusters; the kubelet recreates the static Pod when you save. Then let kube-bench re-check the node:

sudo kube-bench run --targets node
sudo kube-bench run --targets etcd

Every benchmark check carries remediation guidance that names the file or flag involved. Fix the cause, restart the component, and rerun until the check passes.

Common mistakes

• Editing config.yaml while a flag in kubeadm-flags.env or a drop-in sets the opposite value: the flag wins and the benchmark still fails.
• Forgetting to restart the kubelet: the file is right, the process is not.
• Running kube-bench without root: it cannot read every config file, so results are incomplete.
• Fixing one node and assuming the rest follow: each node has its own config.yaml, written by kubeadm from the kubelet-config ConfigMap at join time.

Cleanup: restore your saved files or discard the VMs. References: Kubelet authentication/authorization, Kubelet configuration (v1beta1), Operating etcd clusters, kube-bench. Next, try API server authentication or node upgrades.