The kubelet is the agent that runs on every Kubernetes node and manages its pods. Its API listens on port 10250, and if it allows anonymous access (or is reachable from where it should not be), an attacker can list pods and execute commands inside them without credentials, harvesting secrets and service account tokens. An exposed, unauthenticated kubelet is a direct route from network access to running code in workloads. Lock it down with authentication and authorization.
What the kubelet is
Each Kubernetes node runs a kubelet: the agent that starts the pods the control plane assigns and reports their status. To do that it exposes an API on port 10250.
That API can run commands in pods (it is how kubectl exec ultimately works). If the kubelet is configured to allow anonymous authentication or its port is reachable by attackers, that powerful API is available without credentials.
The abuse and payload
Against a kubelet that permits anonymous access on 10250:
- List the pods on the node:
curl -sk https://NODE:10250/pods - Execute a command inside a chosen pod/container (the kubelet
run/execendpoint), e.g. read its mounted service account token at/var/run/secrets/kubernetes.io/serviceaccount/token. - Use that token against the API server to expand access across the cluster (see service account token).
Documented techniques shown for defenders.
How to defend
- Disable anonymous auth on the kubelet (
--anonymous-auth=false) and require authentication. - Enable authorization (
--authorization-mode=Webhook) so even authenticated callers are checked. - Restrict network access to 10250 so only the control plane can reach it.
- Rotate and scope service account tokens so a stolen one is limited.
- Scan nodes for exposed kubelet ports and test the cluster for this path.
References
- [1]Kubernetes docs: Kubelet authentication/authorization(Kubernetes)
- [2]MITRE ATT&CK: Containers Matrix(MITRE)
- [3]NIST SP 800-190 Application Container Security Guide(NIST)