3 ms·

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 s

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.

tyingq 2y ago
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.
- oneplane 2y ago
  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?
  - rcaught 2y ago
    Permission boundaries
  - tyingq 2y ago
    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.
    - oneplane 2y ago
      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.
      - tyingq 2y ago
        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.
Joker_vD 2y ago
> 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.
- oneplane 2y ago
  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.

tyingq 2y ago

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.

oneplane 2y ago
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?
- rcaught 2y ago
  Permission boundaries
- tyingq 2y ago
  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.
  - oneplane 2y ago
    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.
    - tyingq 2y ago
      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.

Joker_vD 2y ago

> 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.

oneplane 2y ago
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.