That doesn't work for IAM Roles, because (a) AWS library code expects to get the keys out of the metadata store, and (b) IAM Role credentials are periodically rotated, so the keys you downloaded in advance would expire.
You're right it doesn't. IAM roles are intended to be granted to the entire server, not a subset of the server's users. Any compromise of the server would be considered a compromise of its role. Yeah, this is a bit crazy depending on what you're running on it. I was running multi-tenant IIS hosts and the apps had no business with the metadata or ec2 IAM roles in my case.
If you want roles to work for other users via the meta data store you can intercept requests with a proxy and then grab the temp credentials STS assume role. This is how kube2iam works. Depending on your use case you'd have to write the proxy, automate the mappings and firewall rules, etc etc etc. PITA but probably doable.
On a different note, I agree with just about everything you had to say about the PITA that is IAM. Properly scoping permissions is much harder than it needs to be. Not all resources support tags, and even then almost nothing outside of ec2 supports tag conditions in IAM. This leads to many naming schemas and wildcard resource conditions :( AWS should have created the concept of resource groups. This would have greatly simplified giving users permissions to subsets of an accounts resources. I chalk this up to AWS's VERY poor collaboration between service teams. Nothing that came out seemed coordinated. This appears to be getting better (shrug).
It's true that instance profile roles today supply credentials to the entire server. One benefit of virtualization is that it's reasonable to run small, single-purpose VMs. However if you do wish to restrict role credentials to certain processes, there are ways of doing it, such as using EC2 Container Service with task-level IAM Roles [1]:
> Credential Isolation: A container can only retrieve credentials for the IAM role that is defined in the task definition to which it belongs; a container never has access to credentials that are intended for another container that belongs to another task.
If you do firewall the instance metadata service and want to get credentials into individual processes, then you could do that using one of the credential providers in the AWS SDK. I haven't worked with every language SDK, but service clients in the SDK for Java take an AWSCredentialsProvider as input, and you can pick from a number of standard implementations [2] or define a custom one.
> An admin user could fetch these subsets of the metadata and leave a copy of them in the local filesystem.
So if you wanted to take this approach, an admin agent could periodically copy the role credentials as property files into the home directories of users that need them, and then applications could load them by configuring the SDK with ProfileCredentialsProvider (which can refresh credentials periodically). The admin agent could perhaps be a shell script run by cron that `curl`s from the instance metadata service and writes the output to designated files.
One benefit of virtualization is that it's reasonable to run small, single-purpose VMs.
Single-purpose doesn't mean single-user. Lots of services divide their code into "privileged" and "unprivileged" components in order to reduce the impact of a vulnerability in the code which does not require privileges. As far as I'm aware, there's no way to have an sshd process which is divided between two EC2 Containers...
