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?

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.

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