logoalt Hacker News

Aperockytoday at 4:18 PM1 replyview on HN

Some internal perspective - IAM has maybe thousands of options but fundamentally it is "what does this role have access to doing (action + resource)" + "who has access to this role". That is really it from a 10k foot level.

IAM is great because it applies internally just like it does externally. The internal AWS team don't get more access than you do, and if we get access to do certain thing on your account to perform specific service that's because you have a service principle in your IAM trust relationship that allowed us access, that you can see, and audit. For instance, lambdas have lambda role because you don't want lambda service just reading your S3 buckets because "we're AWS we automatically get access", you can absolutely see and control access, even if it is internal to AWS.


Replies

paulddrapertoday at 4:45 PM

> that's because you have a service principle in your IAM trust relationship that allowed us access

That’s why it’s so complicated!!!

I don’t understand how I should evaluate trust for your internal EBS org versus your internal ALB org.

I kinda just expect it to be all “AWS” trust.

And it’s all garbage anyway. There’s no way I can prevent the hypothetically untrustworthy EBS team from surreptitiously adding charges to my account if they want to. Right? This would maybe make some sense if I could top level turn off/on services, but that isn’t how it works.

I have no doubt this makes some sense from someone inside the machine, but from the outside it’s not helpful nor useful.