Holochrome – Log in or switch between your AWS accounts with a single key stroke
github.comInstance metadata does provide rotating credentials, which is a step forward, but in every other way it's a net security loss:
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...
Some points & questions:
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.
If anyone is interested in learning more - I'm giving a quick lunch & learn talk at noon Wednesday, July 27th, at the AWS Pop-Up loft in San Francisco. Check out more details here: https://aws.amazon.com/start-ups/loft/sf-loft/
What's the forensics story (how do you understand after the fact who did what actions) for using IAM roles in this way? To my knowledge, Cloudtrail includes only the assumed IAM role in the actual API actions.
The assumerole api has a session name field which is arbitrary text that's included in cloud trail. Hologram sets this to the users name/email address from ldap
Yeah, all API actions will show up as being from ARN "arn:aws:sts::<account-id>:assumed-role/<hologram role>/<ldap username>"
Seems like this chrome plugin requires you to have Hologram running in order to have local metadata server access.
If you're running on a non-EC2 instance, that's correct.
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.