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.
Yeah, that's the one. I'd done my own analysis before that came out and figured it was an unacceptable risk, and then that article came out with the actual attack vector in all its glory. The simple fact the k8s/etcd ports are exposed on a public address with no ability to firewall it off is bad enough, as you're relying on the security of the software running on those ports rather than a firewall restricting which source address(es) can even connect to begin with.
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.
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.