If you make the choice to say account == project, you're good to go in most cases. If you need deep permission hierarchies, you're screwed unless you go ABAC, b

If you make the choice to say account == project, you're good to go in most cases. If you need deep permission hierarchies, you're screwed unless you go ABAC, but that is not amazingly implemented in any of the big clouds. Another saving scenario might be using a public cloud but not using it for flexible deployments and workloads (which are not the same thing and also indicates that a cloud may not be the best place to do this). Azure is the worst of all worlds because its Azure AD implementation is much better than classic AD but much worse than modern IAM. It's really weird how they made something that on the surface seems like a nice modern replacement but then ends up biting you in the ass as soon as you try to stop playing datacenter-in-the-cloud and actually do something new/innovative. Same goes for GCP and Azure in terms of service credentials when compared to IRSA and Instance Roles, or the other way around, non-standard credentials in AWS vs. OIDC or x509 in GCP (and Azure, and Kubernetes...). Granted, those aren't amazing either, but just for initial identities (after which you should switch into a specific principal - bare user principal policies deserve to be burned). The odd thing about most of this (in GCP and AWS, Azure seems to still have a two-faced API in the 'standard for me but not for thee' style) is that at some point resource interfaces got more and more standardised within each big cloud, yet the IAM part did not grow the same way. Perhaps because it wasn't possible to refactor/discard legacy systems in time (Just like EC2 Classic is only now going into some sort of read-only mode), or the scaling issues weren't apparent early enough? Some scaling solutions are a whole different can of worms, like the folder/inheritance structure which becomes the same mess as AWS with the boundary structure. That is one thing where a more classical "Directory" approach doesn't have this issue as much, but you trade it for the single-OU-leaf-at-a-time issue. Seeing how we do sometimes have to apply the ugliest of kludges for complex IAM scenarios (i.e. a microservice accessing two different resources in different scopes [ AWS accounts ] and some resources support resource-level policies to allow this but others are always IAM-local, so now you have to make your IaC pick the target that has the least flexible IAM context, create the principal there, and refer to that principal from all the remote contexts), you'd think instead of developing shrink-wrapping extensions more focus would be applied to ABAC and resource-local policies... Regardless of the implementation, I do question systems that cannot separate credentials from principals. A principal is what you are granted to BE post-authentication, and you need credentials for that. A policy grants a principal one or more ACTIONS. Therefore, a "user" should be credentials, but not a principal. But this is getting too much into semantics... as long as your authenticity is not tied to your authorisation the system should be better off (even if it ends up calling principals roles - just call users not-principals in that case, and disallow policy attachments or user references). A thing that does make more sense than the author of the article states is making things like this 'just another service'. When you don't do that, but make it 'special' instead, you create a single-root problem. An example is the problem where billing is either in the local account, or in the org account, and nowhere else (in AWS). In GCP your projects and billing accounts are just two resources that can exist in arbitrary numbers and be linked as needed. Billing shouldn't be special, just like IAM shouldn't be special.