Analysis of a Kubernetes Hack

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 :/

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