EC2's most dangerous feature

Re:EC2's most dangerous feature by boulos on Sunday October 09, 2016 @01:33PM (#12672230)

I just double checked, and the most similar thing we expose is the token's for each service-account in the instance metadata. As pointed out in the article, any uid on the box can read that. But, you can create instances with a zero-permission service account (the equivalent of nobody?) and just avoid it.

This does mean that everywhere else you'd have to have explicit service accounts and such, but that seems like a reasonable "workaround" until or unless we make metadata access more granular (I like the block device idea! Would you want entirely different paths for JSON versus "plain" though?)

[ Parent | on HN ]

Re:EC2's most dangerous feature by lobster_johnson on Sunday October 09, 2016 @03:07PM (#12672808)

Google Cloud does seem better here. The exception is GKE — Kubernetes nodes are associated with service accounts which have permissions that, if abused by a malicious Docker container, could be disasterous for your entire cluster.

Considering the amount of unpatched Docker containers out there, that's a bit scary. It also effectively prevents GKE from being usable in any scenario where you want to schedule containers on behalf of third-party actors (think PaaS). (GKE also doesn't let you disable privileged Docker containers, but that's another story.)

On AWS you can run a metadata proxy to prevent pods from getting the credentials, but I don't know of a clean way to accomplish the same thing on GKE.

[ Parent | on HN ]