Kubelet API exposure

What it means

The kubelet is the agent that runs on every Kubernetes node and starts the containers on it. It has its own HTTPS API, normally on port 10250, that lists pods, reads logs and can run commands inside containers. Kubelet API exposure means that API can be reached by people who should not reach it.

The risk lies in the checks. If the kubelet accepts anonymous requests or allows every request that arrives, anyone with network access to the node can ask it to open a shell in a pod. That is node-level control, reached without touching your application at all.

Why it matters

A reachable, unprotected kubelet is a direct route to run code in your workloads, read their environment variables and steal the service account tokens mounted inside them. From there, an attacker can try to reach the control plane and other namespaces.

Clusters with this problem tend to have it for a long time, because nothing breaks. The flaw only shows when somebody scans for it. For a customer-data business, one open port on a node can turn a small cloud mistake into a data breach.

How it shows up

Check the kubelet configuration. Anonymous authentication should be off, and authorisation should be set to Webhook so the API server decides, rather than allowing everything. Block port 10250 from the internet and from networks that have no need of it. Managed Kubernetes services set most of this for you, but custom node images can differ.

The usual causes are a hand-built cluster, an old tutorial configuration, and security groups opened wide during a debugging session and never closed. Include the nodes in your port scans and confirm that the answer to an unauthenticated request is a refusal.