I agree with people saying IAM is not that complicated. On the other hand, I think I also agree that IAM is extremely complicated. It's both. I'm serious!
The problem with IAM isn't the functionality it offers; it's almost exactly what you want. I mean look at what it actually does, isn't it literally exactly what you would do? Sure, maybe the terms are confusing or something, but on the whole... it's hard to argue that what it offers isn't basically what you want. You want to allow identities, to do things. You group those things into roles. And so on.
That said, the more powerful and granular permissions and ACLs get, the more grand the architecture you have to craft to make good use of it, and I think at some point, your own IAM rules become a work of engineering themselves. You wind up having to specifically engineer around and for IAM. This is not unique to cloud IAM; when doing complex NixOS setups, I have occasionally realized that my webs of plumbing secrets through SOPS to systemd units, and setting up group permissions for UNIX domain sockets between services, winds up getting quite complex quite quickly, and that it is basically, yes, engineering of its own sort. And if you add cgroups and network namespaces and nftables rules and seccomp, god help you, it's even worse than IAM! And that's just on a single machine...
IAM is "not complicated and complicated" in the same sense as UI frameworks/ecosystems/boost are. The "concept" is fairly simple, but you have to know a ton of bits and bobs to make sense of it all, for your particular use case. And you often have to dig deeper than you would like.
I don't run any clouds myself but if I were AWS or whoever I'd think there's a whole lot of ways to make this process more ergonomic without sacrificing functionality. A tool that can report permission failures with a "should we allow this yes/n?" button for admins. A user (real or service) tries to run a cache invalidation, or write a redshift DB or add an IP to a security group and gets a "permission denied". Admin gets an email or a ticket saying what process failed and click a button to enable or deny.
Typing that out it's really the massive gulf between the abstraction "User wants to invalidate a cache" vs the implementation of 87 granular grants with obscure nomenclature.
Isn't this already how it works tho? At least in my time doing internships, I would hit some screen saying access needed and just press a couple of buttons tagging my manager and some sec team and soon enough it would be granted or explained that, actually no, I was accessing the wrong stuff, and be pointed in the right way.
This is more or less what the article proposes except the article proposes doing this one time after collecting a full list of actions.
Both that solution and the one in the article miss one point though: If you use the AWS Console at all it makes hundreds of calls to all manners of AWS service in all available regions. Because of this you can't just assume the calls made by a role intended for interactive use over some period are the "correct" privileges for that role because someone just clicking around in the console will generate thousands API calls to many different services.
The problem with IAM isn't the functionality it offers; it's almost exactly what you want. I mean look at what it actually does, isn't it literally exactly what you would do? Sure, maybe the terms are confusing or something, but on the whole... it's hard to argue that what it offers isn't basically what you want. You want to allow identities, to do things. You group those things into roles. And so on.
That said, the more powerful and granular permissions and ACLs get, the more grand the architecture you have to craft to make good use of it, and I think at some point, your own IAM rules become a work of engineering themselves. You wind up having to specifically engineer around and for IAM. This is not unique to cloud IAM; when doing complex NixOS setups, I have occasionally realized that my webs of plumbing secrets through SOPS to systemd units, and setting up group permissions for UNIX domain sockets between services, winds up getting quite complex quite quickly, and that it is basically, yes, engineering of its own sort. And if you add cgroups and network namespaces and nftables rules and seccomp, god help you, it's even worse than IAM! And that's just on a single machine...