4 ms·
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 permission
by egorfine 2y ago
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.
- JackSlateur 2y agoYes 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.
- egorfine 2y agoI'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.
- lijok 2y agoBut they are, that's kind of the whole point. You start with {"actions": ["s3:"], "resources": [""]} and graduate from there when ready.
- egorfine 2y agoThis could be a perfect 101 on IAM which I would strongly prefer never attending.
- lijok 2y agoHow else do you expect to manage permissions? Is there a better dsl design you have in mind?
- egorfine 2y agoWhat 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.
- JackSlateur 2y agoBut 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
- egorfine 2y agoYou 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.
- danielheath 2y agoIf 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.
- xenophonf 2y ago> 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.
- egorfine 2y agoWholeheartedly 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.
- icedchai 2y agoThey basically are optional. You can use wildcards in the action. (Nobody will go back and tighten them up though.)
- egorfine 2y agoThey aren't. To have wildcards I still have to go to IAM and learn how to create a wildcard policy.
- icedchai 2y agoBut 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...
- inopinatus 2y agoThe 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
- cqqxo4zV46cp 2y agoNo. 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.
- egorfine 2y ago> 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.
- Aeolun 2y ago> 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)