Kubernetes: Potential unauthorized Kubelet API access from containers

Adversaries may attempt to interact with the Kubelet API from within a container to gain visibility into the node, enumerate pods, or execute commands on the host. This behavior is typically observed when command-line utilities such as curl or wget are invoked from an interactive container shell to reach the Kubelet API port. Unauthorized access to the Kubelet API facilitates lateral movement and potential privilege escalation within a Kubernetes cluster.

Attack Chain

1. Initial access to a container via exploitation or misconfiguration.
2. Execution of an interactive shell within the container.
3. Reconnaissance of the local node or cluster network to identify Kubelet API endpoints.
4. Execution of HTTP/WSS requests directed at the node Kubelet API (port 10250 or 10255).
5. Enumeration of cluster resources, pod logs, or execution of commands via API endpoints such as /exec, /run, or /containerLogs.
6. Escalation of privileges or lateral movement to other cluster resources.

Impact

Successful unauthorized access to the Kubelet API can lead to full cluster compromise, unauthorized pod execution, and exposure of sensitive container logs or environment variables.

Recommendation

• Deploy the provided detection rule to monitor for process executions involving Kubelet port access from containers.
• Implement network policies to block egress traffic from container namespaces to node-local Kubelet ports (10250/10255).
• Harden Kubelet configurations by disabling anonymous access and requiring authenticated, authorized webhook requests.
• Remove administrative tooling (e.g., curl, wget, shell access) from production container images.
• Rotate sensitive credentials, including service account tokens and client certificates, if unauthorized Kubelet API requests are detected.