Hacker News new | ask | show | jobs
Analysis of a Kubernetes Hack (medium.com)
8 points by jc_sec 3021 days ago
2 comments
terom 3020 days ago
kubeadm seems to configure the kubelet with `--authorization-mode=Webhook`, which prevents the use of the exec API by unauthenticated users:

  $ curl -vk -X POST https://...:10250/exec/test
  ...
  < HTTP/1.1 403 Forbidden
  ...
  Forbidden (user=system:anonymous, verb=create, resource=nodes, subresource=proxy)
OTOH some endpoints on the `--read-only-port=10255` API are completely open for unauthenticated requests... that leaks all the pod metadata/spec/status information:

  $ curl http://...:10255/pods
  {"kind":"PodList","apiVersion":"v1","metadata":{},"items":[{"metadata":{"name":"kube-proxy-knfqg","generateName":"kube-proxy-","namespace":"kube-system", ...}
Not what I expected, and the `--authorization-mode=AlwaysAllow` default seems like a very bad idea :/
link
alpb 3021 days ago
I'm trying to understand what the issue here was. Did they publicly expose the kubelet port on the internet?
link
jc_sec 3021 days ago
Yep. The kubelet ports were exposed. From the article:

As it turns out, our coworker’s server was also publicly exposing the kubelet ports (tcp 10250, tcp 10255). Although the problem here was obvious, it should raise some questions about your own Kubernetes deployment, as it did for us.

link
jc_sec 3021 days ago
Try a quick nmap scan on an AWS or Google IP range for tcp port 10250 to see some scary results.
link