5 ms·
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 l
by JackSlateur 2y ago
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
- MrBuddyCasino 2y ago> I cannot imagine how we could make it different This seems almost bait.
- egorfine 2y agoProblem is, once you dive deep in the rabbit hole, you will inevitably build another IAM. The art here is knowing when to stop building, not what to build.
- cqqxo4zV46cp 2y agoThis is a great way to avoid voicing constructive criticism about IAM that doesn’t end up being “hard-code it for my use case at the expensive of making it difficult for a significant portion of other customers”.
- nprateem 2y agoWell, for a start, you could have a recorder that actually shows all the relevant permissions for a particular API call so users can work out what they should set permissions on (including interactions with SCPs and anything else that could affect a decision).
- rad_gruchalski 2y agoYou can easily get the first part of via the sdk https://cloudonaut.io/record-aws-api-calls-to-improve-iam-policies/ https://cloudonaut.io/record-aws-api-calls-to-improve-iam-po....
- Aeolun 2y agoYou can actually set this up in your account. It’ll record all the permission your roles actually use (over a customizable period of time), so you can remove all others
- egorfine 2y agoI 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.
- myaccountonhn 2y agoI don’t think the language is bad, but maybe improve the policy simulator, make it easier to understand what policies are require and also make it easier to find and reference different arns.
- whs 2y agoI wish it is a list of <who, what, which>. Right now you can't even get a comprehensive list of people who can access this S3 object. Add assume roles, conditional access, cross account, per-service object level policy into the mix I don't think it's even actually possible for AWS to implement that. 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)
- JackSlateur 2y agoYou are right : "much simpler but more limited" And because you can limit yourself, you can effectively simplify your way of consuming IAM "He who can do more can do less"
- tyingq 2y agoThe way it evolved makes it complicated. That you have normal policy, resource attached policy, SCP, Assumed roles, etc, etc. 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".
- oneplane 2y agoI'm not sure how that is complicated. There are different systems with different functions for different purposes, that will not go away unless you remove the systems or the purposes. And that's not useful.
- tyingq 2y agoOkay yes, I figure out what I need to. But it seems clear that conflicting concepts got bolted on after the initial design. Which means it's more complicated than it needs to be.
- oneplane 2y agoWhich ones are bolted on? Besides the S3 ACLs (which are more like a precursor) and the weird conditional language it's all pretty consistent and obvious like any ACL. 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?
- rcaught 2y agoPermission boundaries
- tyingq 2y agoYou can't meld the rules together to get a cohesive view of, for example, "who can access this S3 bucket?". Because, for example, an SCP can override a bucket policy. And policies can be other places too. 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.
- randomtoast 2y agoAWS is good at building abstractions on top of their already existing features, e.g. AWS App Runner. Maybe there could be an abstraction on top of IAM that does not allow for all the fine-grained permissions settings and options that IAM has, but has much simpler predefined roles which are very well suited for a small startup.
- nerdjon 2y agoFor a lot of situations they already have this. They have managed (AWS Created and Managed) policies that if you want a basic level of security you can use. 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.
- icedchai 2y agoThe main problem is it's a huge time suck. When writing IAC like Terraform, you'll probably spend more time configuring IAM roles and permissions than you do the actual infrastructure. Also, in my experience, nobody reviewing your code will check if it's correct, least privilege, etc. And when you get it wrong (too restrictive), the error messages can be difficult to diagnose, depending on the service. So most people will err on the side of more permissions than needed.
- presspot 2y agoI have hard this from many developers. Are there any good solutions or best practices I should look into?
- guiriduro 2y agoFor the security sanity checking of terraform infra code, take a look at Checkov.
- turtlebits 2y agoDon't use Terraform? If you want to create individual resources one by one, go for it. Use something like CDK which abstracts a lot of the boilerplate away.
- icedchai 2y agoI wound up with a job at a TF-heavy company. I personally despise Terraform. The language is anemic and there's too much copy-paste code.
- sgarland 2y ago…and compiles into CloudFormation, which is of the devil. 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.
- dopylitty 2y agoIt’s a little more complicated than that. I’ve run into many instances where a particular Action involves many different Resources. 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.
- jimberlage 2y agoI think this gets at my ick with IAM. If AWS knows it needs “s3:ListBuckets” for a call to function, why doesn’t giving permissions on that call just imply that I gave it the “s3:ListBuckets” permission too? 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.
- wetpaste 2y agoI think it gets hard when an emergent chain of complex trust relationships need to be built and understood. Things like IAM identity center, workload identity, IRSA on EKS, service principals vs roles for accessing other services from a service, resource policies vs principle-level policies and when to use each. Not necessarily intuitive all the time. I don't think it's THAT hard and I understand why some of these things were built this way, but it's a huge complicated ecosystem of services and I understand why it can get confusing to some. Gotta be disciplined about it.
- egorfine 2y agoIt's not THAT hard if that's the thing you specialize about. 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.
- danielheath 2y ago“Record mode”, where for 24h all permissions are automatically granted on first use, would be an obvious improvement. The ability to measure what permissions you need and record them automatically would improve the onboarding experience immeasurably.