Comment by bob1029
6 hours ago
I strongly disagree with the part about IAM roles for EC2
> a useful improvement (especially given the urgency after the Capital One breach) but in my view just a mitigation of one particular exploit path rather than addressing the fundamental problem that credentials were being exposed via an interface which was entirely unsuitable for that purpose.
What alternative interface does the author propose we use to securely exchange credentials? The only other approaches I can come up with involve allowing monkey hands to come into direct contact with secret materials. Outlook, slack and teams cannot possibly be more secure than IMDSv2. I think if you are manually passing around things like PFX files you've already lost the game.
The entire point of the IAM roles is to make everything a matter of policy rather than procedure. The difference here is insane when you play through all of the edges. IAM policy management is significantly easier to lock down than the alternative paths. I can prove to an auditor in 5 minutes that it is mathematically impossible for a member of my team to even see the signing keys we use for certain vendors without triggering alerts to other administrators. I've got KMS signing keys that I cannot delete with my root account because I applied inappropriate policies at creation time. This stuff can be very powerful when used well. Azure has a similar idea that makes accessing things like mssql servers way less messy.
What alternative interface does the author propose we use to securely exchange credentials?
If you read the linked post you'll see that at the time I suggested using XenStore to pass credentials to the OS kernel. Obviously a different approach would be needed with Nitro but if anything it would be easier now.
Once the kernel had them they could be exposed to applications via a synthetic filesystem which, crucially, can have ownership and permissions set on it.
I'm absolutely not arguing against IAM Roles for EC2. I'm arguing that they picked the worst possible interface over which to transmit those role credentials.
Scaleway's equivalent only allows connections from ports <1024. This is cute and means only processes with CAP_NET_BIND_SERVICE can retrieve the tokens.
You can do similar with vsock(7) sockets. This also has the advantage that it's harder to trick an application into making a connection to a vsock socket.
Both of these have the weakness that it is not entirely atypical to give processes CAP_NET_BIND_SERVICE so they can listen on "privileged" sockets, but they work against anything without that.
Even better, you could put bootstrap credentials in DMI data or similar, where it'll end up (on Linux) inside a sysfs directory which can only be read by root.