I find IAM to be a great product. I cannot imagine how we could make it different, without removing some of its capabilities: after all, this is nothing but a list of <who, what, on which> permissions
I disagree that IAM specifically is a great product. It's great if you learn it, but learning permissions system never adds anything to the bottom line. It's an evergrowing technical debt at best. People interested in learning permissions system are typically people interested in developing one. Users are never happy with permissions systems because more often than not it's a nuisance.
In my view IAM is an incredibly overengineered list of who, what, which, suitable for corporate granularity but then too complex to be used by a startup or a project.
You are diving into another topic: "fine-grained permissions"
In my opinion, fine-grained permissions is a very good idea for application-attached role: your lambda can only do "this", your ec2 instance can only do "that". For humans, they are a mistake and shall be avoided.
Like let me start the development first. I'll get to security later. I came here for object storage, don't force me to learn an incredibly complex auxiliary service.
Better for small teams? Sure: a login/password system with maybe optional restrictions on services and maybe "readonly" access and maybe with disabled aws console.
Basically, something that was in AWS before the IAM madness came in.
Create IAM user with access/secret keys are easy
Assign the built-in ReadOnly policy, easy too, or any other built-in "generic" policy
Of course, it is possible with IAM because IAM is a top-tier ACL system.
The point: I don't want to learn it.
“Everything has root” is fine when you are starting a new thing - what’s needed is tooling to start there and grow into fine grained permissions when you add a second thing.
And that's why the world is full of crappy, insecure software. Security is ever an afterthought.
And this is also why you need a PhD to fully comprehend it
For the record, I’ve never been in a development team of more than 4 people, and my teams have always been responsible for their own ops. No ‘corporate dev’ here.
True.
> That doesn’t mean that it’s important,
Not necessary true.
> or that the complexity is avoidable.
Untrue. There is no need for IAM for the vast majority of 4 people teams and there could be a simpler solution for those, like it was before IAM. And it can actually be built on top of IAM, just spare people from diving deep into it.
To some extend. It’s perfectly possible to make a role that allows S3 access to any action on everything, but still restricts the service from operating on any of the other 400 AWS services (unlike root credentials)
I also have issues with infrastructure being declared imperatively. I’ve seen countless bugs and incidents caused by CDK surprises.
You get precisely what you ask for with a declarative language.
If you’re trying to do fine grained permissions you have to know every resource that might end up in the request context and then have an entry in a Resource section of a policy for that Resource type. For instance just creating an EC2 (RunInstances) might involve Subnet, Security Group, EBS, image, volume, snapshot, and a few other resource types.
This gets even more complicated when you’re using Condition operators because the conditions are checked against every resource in the request context but each resource type has different valid conditions (eg some resources have tags and some don’t) so you have to split up the policy into numerous statements specific to each resource type.
All of that would be fine if there was any way to actually reliably get the context of a request so you can see exactly what was denied. Sometimes you can get the context via the encoded authorization message in a failed API call but this is usually truncated in CloudTrail or if you’re using IaC tools like Cloudformation.
They’ve done a lot in the past few years to explain why a particular call was denied but none of it beats seeing the context and seeing exactly which part of the policy did or didn’t apply.
For enterprises that genuinely want the finer grained control, let them express that they want to opt out of that implicitness in the policy document.
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".
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?
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.
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.
Which are interconnected, right? If yes, then that's what the word "complicated" means: made of multiple, non-trivially interacting parts.
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.
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 found GCP's access control to be much simpler but more limited than AWS. They're adding complexity though with conditional access. In GCP the "who" in most case is an email (Google Account, Google Groups, service account)
And because you can limit yourself, you can effectively simplify your way of consuming IAM
"He who can do more can do less"
The ability to measure what permissions you need and record them automatically would improve the onboarding experience immeasurably.
Problem is, that kind of things are the backend of the backend. An accessory of an accessory. No business cares about it. Ever. And yes, running wildcard policies can hit you hard if not attended properly; my point is I don't want to learn a complex ACL system made for enterprise for my small startup that is actually gonna be fine with wildcard policy basically forever.
This seems almost bait.
The art here is knowing when to stop building, not what to build.
A lot of services will create policies for you, for example you can go to RDS and click setup connection to lambda, or ec2 and it will create the policy.
A lot of things will give you the policy to copy and paste.
Another UI to further abstract IAM would likely just complicate things, and then make it harder later if/when you need to leave that abstraction.