Kubernetes Kubelet API Abuse via `nodes/proxy` and Cloud-Native Attack Chains

New technical writeups highlighted how seemingly read-only Kubernetes permissions can be escalated into remote code execution (RCE) by abusing access paths to the kubelet API. Horizon3.ai detailed a technique where a service account granted nodes/proxy GET (often treated as “read-only” for monitoring/log access) can, if it also has network reachability to the kubelet, be leveraged to execute commands in pods on reachable nodes—an outcome the Kubernetes project has largely treated as “working as intended” rather than a traditional vulnerability. The post emphasizes that this can translate into broad cluster compromise in many real environments and points to mitigations such as tightening RBAC and adopting controls aligned with KEP-2862 and vendor RBAC hardening guidance.

Separately, a bug-bounty case study described an end-to-end cloud-native kill chain culminating in Kubernetes takeover: an initial SSRF in a microservice was used to access EC2 instance metadata and steal cloud credentials, which then enabled kubelet API abuse to deploy a rogue privileged pod. From that foothold, the attacker obtained a more powerful Kubernetes service account token and escalated to cluster-admin, resulting in full cluster control and a reported $100,000 responsible disclosure payout. While the initial access vectors differ, both accounts reinforce that kubelet exposure plus permissive RBAC/service-account design can turn “limited” access into cluster-wide impact, making kubelet reachability and nodes/proxy/kubelet-related permissions high-priority review items for Kubernetes security programs.