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.
