Live data from Hacker News

IAM Is the Worst

matduggan.com

61–70 of 102 posts

Re: IAM Is the Worst

#61
post #40

I agree with people saying IAM is not that complicated. On the other hand, I think I also agree that IAM is extremely complicated. It's both. I'm serious! The problem with IAM isn't the functionality it offers; it's almost exactly what you want. I mean look at what it actually does, isn't it literally exactly what you would do? Sure, maybe the terms are confusing or something, but on the whole... it's hard to argue t…

IAM is "not complicated and complicated" in the same sense as UI frameworks/ecosystems/boost are. The "concept" is fairly simple, but you have to know a ton of bits and bobs to make sense of it all, for your particular use case. And you often have to dig deeper than you would like.

Re: IAM Is the Worst

#63
post #60
post #57

Whether you agree with the article's recommendations or not, I do not understand how there are so many commenters saying "IAM is not that complicated". Even engineers internally at AWS frequently get tripped up with IAM permission settings. It's rare that someone gets them right on the first try. Just some of the things that make it challenging: 1. There are permissions at various layers. If anything along the chain…

> 1. There are permissions at various layers. If anything along the chain doesn't line up, permission denied. - I am shocked that you don't seem to find Deny By Default the best thing in the world... (looking at you Azure...) > You need deep understanding of each service's specific IAM setup. - Color me shocked... > Ancillary permission requirements are not obvious if you're not familiar with the details of how a ser…

Lol. “You’re just holding it wrong”.

If most people find it to be difficult to use correctly, it is difficult to use correctly. Maybe that’s the best we can do but it’s still bad.

Re: IAM Is the Worst

#64
post #60
post #57

Whether you agree with the article's recommendations or not, I do not understand how there are so many commenters saying "IAM is not that complicated". Even engineers internally at AWS frequently get tripped up with IAM permission settings. It's rare that someone gets them right on the first try. Just some of the things that make it challenging: 1. There are permissions at various layers. If anything along the chain…

> 1. There are permissions at various layers. If anything along the chain doesn't line up, permission denied. - I am shocked that you don't seem to find Deny By Default the best thing in the world... (looking at you Azure...) > You need deep understanding of each service's specific IAM setup. - Color me shocked... > Ancillary permission requirements are not obvious if you're not familiar with the details of how a ser…

> - I am shocked that you don't seem to find Deny By Default the best thing in the world... (looking at you Azure...)

The problem is not deny by default, but the complexity of setting "allow just the things I need". This is not easy.

> Cloudtrail is your friend...

Having to dig into the data of another service (that hopefully your org permissions allow you to read) instead of just being able to see a clear error message is not great DX. There are maybe valid security or performance reasons for not returning clear error messages, but there is a trade-off to usability made here.

> At least for AWS, you are not supposed at any point in time to use out-of-the-box managed policies. Instead, you should use them as templates for your own policies or create your own Customer Managed Policies from scratch.

Right, but because they're so broad, the templates themselves are overly broad. Even just using them as a reference, it's difficult to pare down to just what you need. You will inevitably go too far and have to play around with combinations until you identify the real need.

---

The rest of your comments essentially boil down to saying "skill issue"/"git gud". I think that downplays just how hard these things are to get right. I worked at AWS for almost 8 years and have used it for several more years as a customer since then. I still wind up with runtime errors due to permissions issues that I need to debug. I still find myself needing to spend lots of time shuffling through official docs and blog posts people have written about how to setup specific combinations of AWS services. I've seen other engineers within AWS struggle with this. I've spoken with many founders at startups who've struggled with this. The biggest challenge comes up when first learning and getting acquainted with a service. You don't even know what you don't know and there are many hurdles that can pop up along the way.

I mentioned it in my last comment, but CDK is probably the single biggest improvement to DX in the space here.

Re: IAM Is the Worst

#65
I think the usual part of AWS IAM is simple. You develop your app, it uses a Lambda role or an ECS task role, and you keep adding permissions to the role as needed. When you query a new table in DynamoDB, your app won't work until you add the missing permission. You always add those permissions to the CDK/CloudFormation definition of the role, so that the role works in any AWS account the app is deployed to. CDK actually handles most of this automatically, as you define the relationships between your cloud resources.

The more complicated stuff starts happening when you have many services that need to access each other's resources directly. Then you need to think a bit more about the architecture and how you expose resource names, managed policies and roles between services. It's no longer just simple role definitions within the CloudFormation stack, but you have to pass around account identifiers, regions and resource ARNs in the configuration.

Re: IAM Is the Worst

#66
post #60
post #57

Whether you agree with the article's recommendations or not, I do not understand how there are so many commenters saying "IAM is not that complicated". Even engineers internally at AWS frequently get tripped up with IAM permission settings. It's rare that someone gets them right on the first try. Just some of the things that make it challenging: 1. There are permissions at various layers. If anything along the chain…

> 1. There are permissions at various layers. If anything along the chain doesn't line up, permission denied. - I am shocked that you don't seem to find Deny By Default the best thing in the world... (looking at you Azure...) > You need deep understanding of each service's specific IAM setup. - Color me shocked... > Ancillary permission requirements are not obvious if you're not familiar with the details of how a ser…

I'm not the person you're condescending to, but it is possible IMO to simultaneously recognize the security value in deny-by-default and Principle of Least Privilege while also finding it challenging to work with AWS's IAM permissions in practice.

Re: IAM Is the Worst

#67
post #60

Earlier quoted context omitted.

> 1. There are permissions at various layers. If anything along the chain doesn't line up, permission denied. - I am shocked that you don't seem to find Deny By Default the best thing in the world... (looking at you Azure...) > You need deep understanding of each service's specific IAM setup. - Color me shocked... > Ancillary permission requirements are not obvious if you're not familiar with the details of how a ser…

Lol. “You’re just holding it wrong”. If most people find it to be difficult to use correctly, it is difficult to use correctly. Maybe that’s the best we can do but it’s still bad.

I always heard an F-16 it's a pretty easy to fly airplane ...For trained pilots. Maybe I have done Consulting at too many Startups or large Enterprise with large Cloud deployments, where most of the team seems to have barely spent some time with the docs. Some even proudly state they learned it by "looking in with colleagues"...or "on the job". Yes, it's Friday and that makes me grumpy...

Re: IAM Is the Worst

#68
post #50

Earlier quoted context omitted.

GCP has a glaring problem with temporary privileges. The console doesn’t support them. So if there is some operational activity that a user needs to do via gui rarely you either have to manually give and take those permissions or let them sit with elevated permissions all the time. And the lack of roles of roles is beyond idiotic, it’s downright dangerous.

Just temporary add the user to yet another group with the needed permissions. Or use the IAM conditional policy. Or impersonate a service-account (which is more or less the same as asuming AWS role) GCP's lack of "AWS role" concept is great and straigtforward. As well as its lack of both identity-bound policies and resource-bound policies at the same time.

You can’t impersonate a service account with the console.

The rest of those are either manual or too broad.

Re: IAM Is the Worst

#69
post #60

Earlier quoted context omitted.

> 1. There are permissions at various layers. If anything along the chain doesn't line up, permission denied. - I am shocked that you don't seem to find Deny By Default the best thing in the world... (looking at you Azure...) > You need deep understanding of each service's specific IAM setup. - Color me shocked... > Ancillary permission requirements are not obvious if you're not familiar with the details of how a ser…

I'm not the person you're condescending to, but it is possible IMO to simultaneously recognize the security value in deny-by-default and Principle of Least Privilege while also finding it challenging to work with AWS's IAM permissions in practice.

The same way the person is condescending to the ones who don't find so difficult. I would even go and argue, that if you are already having issues with IAM, how do you expect to handle what is actually difficult?

Re: IAM Is the Worst

#70
post #16

Earlier quoted context omitted.

These guys are often hired to implement regulation or certification requirements and the organization, if its goal is to comply, has to change its behavior and processes. Not saying your point is not true, I met guys who did it just because too. But it's not always malice or incompetence on their part.

My experience is that both of you are right: the security people implement important regulations, and they do so without ever looking at the business processes themselves. Then it's up to the targeted people to chase exceptions and recategorization and and and, which on one hand creates a friction which eats up lots of resources and time, and secondly pokes holes in that exact perfect structure it was supposed to cre…

That’s because businesses goals are to make something work, and securities goals are to stop something from happening (or comply with a process with that goal in mind).

Hopefully not the same ‘thing’ being targeted of course, because then it will get really bad, but yes conflict is inevitable.

Post reply on HN