
Analysis of a Kubernetes Hack - jc_sec
https://medium.com/handy-tech/analysis-of-a-kubernetes-hack-backdooring-through-kubelet-823be5c3d67c
======
terom
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 :/

------
alpb
I'm trying to understand what the issue here was. Did they publicly expose the
kubelet port on the internet?

~~~
jc_sec
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.

