Not only are your cluster's administration ports exposed on public addresses with no ability to firewall them, but each node pulls an Admin-level auth token to manage the DigitalOcean account behind the scenes. A single http request made to an internal IP, from within any Docker container running within the cluster, grants the attacker full read/write access and control to the underlying DigitalOcean account. This includes any developer who does so from code deployed into the cluster, giving the developer full access to the business's DigitalOcean account.
I'm curious as to whether that has been fixed and a proper security evaluation done. I've been avoiding k8s on DO for a while because of that (perfectly comfortable with their other services) but it would be good to get an update.
The credentials (certificates) being exposed via http://169.254.169.254/metadata/v1/user-data – from within any pod/container, not just from a physical node – was the final straw. I'd forgotten that the DO token wasn't directly listed there, but can be extracted from the etcd instance where it is stored (explained under "DigitalOcean Account Takeover" of that article).
Again, all of this may have been (and hopefully has been) mitigated since the original release. For me, it's too late to reevaluate; the fact that was considered releasable in the first place destroyed any credibility in my eyes.
Very happy with it, also the resources available helped a lot in actually understanding k8s. On GCP the line between what gcloud and what k8s was a bit blurry for someone new like me, and doing just k8s on DO helped me really 'getting it'.