But they are, that's kind of the whole point. You start with {"actions": ["s3:"], "resources": [""]} and graduate from there when ready.

This could be a perfect 101 on IAM which I would strongly prefer never attending.

How else do you expect to manage permissions? Is there a better dsl design you have in mind?

What is better? I am pretty sure IAM is the best there is, no questions about that.

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.

But you can do that with IAM, and quite easily too

Create IAM user with access/secret keys are easy

Assign the built-in ReadOnly policy, easy too, or any other built-in "generic" policy

You are missing my point.

Of course, it is possible with IAM because IAM is a top-tier ACL system.

The point: I don't want to learn it.

If my account has only got one thing in it, I don’t expect to manage permissions at all.

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

> Like let me start the development first. I'll get to security later.

And that's why the world is full of crappy, insecure software. Security is ever an afterthought.

Wholeheartedly agree with you. Not only it's an afterthought, it's a sinkhole for resources with zero apparent ROI. It's basically lives in backlog rent-free.

They basically are optional. You can use wildcards in the action. (Nobody will go back and tighten them up though.)

They aren't. To have wildcards I still have to go to IAM and learn how to create a wildcard policy.

But you don't have to list each and every permission, which was my point. This is far easier than investigating what your app does, mapping it to permissions, missing some of them, and iterating...