Hacker News Reader

Comment by tyingq | Hacker News Reader

The way it evolved makes it complicated. That you have normal policy, resource attached policy, SCP, Assumed roles, etc, etc.

That spreads out the actual end resulting policy into a bunch of disparate corners that's hard to unravel.

There's tools to see "can this specific user/role/service get to this thing". But because of the above, there's no one place to see "who can/cannot get to this thing".

View on HN

I'm not sure how that is complicated. There are different systems with different functions for different purposes, that will not go away unless you remove the systems or the purposes. And that's not useful.

Okay yes, I figure out what I need to. But it seems clear that conflicting concepts got bolted on after the initial design. Which means it's more complicated than it needs to be.

Which ones are bolted on? Besides the S3 ACLs (which are more like a precursor) and the weird conditional language it's all pretty consistent and obvious like any ACL.

Things like principals, resources, trusts and control policies are all distinct systems with different goals and purposes. Maybe I'm missing some different AWS IAM policy that has that bolt-on flavour?

You can't meld the rules together to get a cohesive view of, for example, "who can access this S3 bucket?". Because, for example, an SCP can override a bucket policy. And policies can be other places too.

I can get "can this specific role/user access this specific bucket", just not the other direction.

It's not because the language isn't consistent, it's because the language isn't backed by a single cohesive RBAC type setup.

I'm not sure how that makes it a bolt-on or conflicting or complicated. It is indeed not a simple central spreadsheet of 'who can do X on Y', but that would not be feasible at AWS scale.

Microsoft tries that with Entra and it's a pretty miserable experience. Google has CEL for the conditionals which is neat, but it gets rather close to software engineering rather than IAM configuration at that point. The somewhat hierarchical nature they use is also not as great as it seems on first glance.

Yeah I'm not saying I can't use it. I'm just trying to explain why people might look at it and feel like it's not unified.

Permission boundaries

> There are different systems with different functions for different purposes,

Which are interconnected, right? If yes, then that's what the word "complicated" means: made of multiple, non-trivially interacting parts.

You can choose to interconnect them but that is neither required nor default. It depends on what you want to build.

You can have a simple policy on a resource that just allows something, or you can make a complicated bi-directional set of policies that refer to specific principals, resources and actions to constrain it more. That will never go away if that is what you need to build. And it is still optional because if you don't want to build that, then you just end up with your single, not-inter-connected policy.

Imagine, you drop IAM and revive the good old user/password system.

You have no way to see "who can/cannot get to this thing". Yet who could argue that user/password are "complicated" ?

NB: using IAM access/secret key has indeed the same issue

I'm not arguing for user/password.

Reply on news.ycombinator.com