Hacker News Reader

Comment by egorfine | Hacker News Reader

I tend to agree with you that the idea of a list of "who, what, which" is straightforward and probably is the right way of doing things. I agree that permissions is inherently a hard problem.

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.

View on HN

No. You’re in denial about the importance of authorisation, don’t want to give it the time it deserves, and are shooting the messenger in placing the blame on IAM to the degree that you are. People see AAA as a pain in the ass because it’s not the problem they thought they’d need to solve. That doesn’t mean that it’s important, or that the complexity is avoidable.

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.

> People see AAA as a pain in the ass because it’s not the problem they thought they’d need to solve.

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.

Yes

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.

I'd love for fine-grained permissions to be optional. Not an insurmountable barrier to the actual service.

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.

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

The true purpose of IAM is for AWS control-plane and data-plane elements to interact autonomously with resources that are in your account without violating the dialectic around security “of the cloud” vs “in the cloud”.

And this is also why you need a PhD to fully comprehend it

> suitable for corporate granularity but then too complex to be used by a startup or a project

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)

Reply on news.ycombinator.com