E-KUB
kubeletctl
CLI that talks directly to a node's Kubelet API to list pods, exec into containers, and pull logs — most valuable against a kubelet left open to anonymous access.
OVERVIEW
kubeletctl (cyberark/kubeletctl) is a CLI built specifically around the Kubelet API — the per-node agent's own HTTP interface, separate from and normally less protected than the main Kubernetes API server. It wraps both the documented endpoints (listing running pods, retrieving container logs and metrics) and the undocumented ones, most notably the debug run/exec endpoints that let a caller execute a command inside any container the kubelet manages.
Its scan subcommand sweeps a CIDR range for kubelets that respond without authentication — a legacy default on some distributions and a recurring finding in unmanaged or self-hosted clusters — and flags which of those exposed kubelets also allow anonymous command execution, turning a single exposed node into direct code execution inside every pod it hosts.
USE CASES
Practical use cases
- 01
Sweeping a node/subnet range for kubelets exposed without authentication (`scan rce`, `scan token`).
- 02
Listing the pods and containers running on a target node once an exposed kubelet is found.
- 03
Executing commands inside a container directly through the kubelet API, without going through the main API server or needing an RBAC grant at all.
- 04
Harvesting mounted service account tokens from containers reachable via an anonymous kubelet, as a path to escalate into the cluster's normal RBAC-protected API.
QUICK START
When enumerating a node/subnet range for kubelets that respond without authentication, and following up on any that do.
- Confirm the node/CIDR range being tested for kubelet exposure is inside the agreed scope — this bypasses the Kubernetes API server and its RBAC entirely.
- Run a scan across the target range to find kubelets responding without authentication.
- Against a hit, list running pods and containers to see what is reachable.
- Where in scope, attempt command execution in a container and note whether it also exposes a usable service account token.
kubeletctl scan rce --cidr 10.0.0.0/24BEFORE YOU RUN IT
What to check before running it
The finding here is usually the exposure itself — an anonymous, unauthenticated Kubelet API (default port 10250) is a cluster misconfiguration, not a vulnerability in kubelet or kubeletctl; report it as such.
Executing commands or pulling logs through an exposed kubelet directly affects the workloads on that node — treat it like any other remote command execution and stay within the agreed rules of engagement.
A kubelet that refuses anonymous requests isn't necessarily hardened everywhere else — a valid but over-scoped node or client certificate can produce the same access, so don't stop testing at 'anonymous access is disabled.'