1) All instance metadata, including IAM roles, are available to every user and every process on the instance for the life of the instance.
2) You cannot externally terminate access to credentials for the life of the instance (all instance metadata sticks around until the box is stopped or terminated).
3) You can not internally terminate access to credentials (for example, by removing a file)
4) STS session tokens are invisible (you can't audit them) and irrevocable[1] before their expiration.
5) Instance metadata is usually only available on AWS instances
As an AWS Certified SA (but otherwise not affiliated except for my startup (plug: https://userify.com, Team SSH key management) being an AWS tech partner and AWS funds our tech (ty AWS!)), I prefer a root-only file backed into the AMI that can be actually deleted/shredded from the instance after the relevant processes have started and it's read into RAM -- but of course anyone who gains root can scan memory for keys anyway, so this is not fool-proof either, but it's far safer than instance metadata. (Unfortunately, you need to rotate keys frequently if you do it this way, and that is absolutely not automated like STS is.)
However, for fast development and testing, IAM instance roles (aka instance profiles) are great.
1. https://danielgrzelak.com/backdooring-an-aws-account-da007d3...
1. It's pretty easy to add iptables rules to 169.254.169.254 by uid and gid, achieving roughly the same restriction as file-based access. Not the case on Mac OS (although you can do something similar with pf) but almost nobody ever uses a Mac in a multi-user setting anyway.
2. Doing anything to the IAM role behind the instance profile will definitely affect the credentials on the system (they won't retain permissions that are no longer valid in the current role policy). I haven't tried removing the role from the instance profile while it's running. Are you saying that that doesn't work? That's disappointing.
3. You can iptables blackhole it, but you're right that root can still recover access to it. Hasn't really affected me in practice though.
4. Can you elaborate on this a bit? They're definitely traceable through CloudTrail (you see who issued the credentials and what session identifier they use is branded into the ARN), although you'll never see the actual random token material. I haven't had a need to do that though. Is that what you mean?
5. Hologram simulates it on other systems, and works quite well.
However, I could imagine a use case wherein you need to provide a user with a small, locked down set of permissions to your AWS account. If that were the case, you could spin up a jump host with an IAM role that guarantees they're only capable of doing exactly what you allow them to do.
