Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IAM Is the Worst

matduggan.com

Post reply on HN
Print view View original

71–80 of 102 posts

Re: IAM Is the Worst

#71

Post by ElevenLathe »

bilalq wrote: 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…

This is all true, and it's a pain, but the situation is still improved from 20 years ago, when all of these layers were in separately-managed systems with no integration at all. Need to access the database? Well, it's in another datacenter that we haven't added to the backbone yet, so it'll need to traverse the internet. That means you'll need an ACL to get to the outbound NAT -- talk to datacenter team A for that. Then you'll need an ACL at Datacenter B to let your NAT'd IP in -- ticket datacenter B for that, we don't have any of our own people there. Then you can talk to the DBAs to get a username and password -- make sure they lock it down to just the schemas you need, for reasons of least-privilege. At a large org you probably still have to talk to all those teams, but at a well-run one the conversation can be streamlined to a few pull requests against their IaC. At a small org running on one account, you can probably do it yourself in one merge. AWS and GCP (not sure about Azure, but maybe them too) both now also offer relatively painless ways of auditing roles to see what permissions are actually in use, so you can trim them to what is needed. This kind of feature is not really feasible with the permissions spread across 5 heterogeneous systems.

Sure, we could just put everything on one VLAN and hand out . credentials, but you can do the equivalent in the cloud too.

Re: IAM Is the Worst

#72

Post by dopylitty »

bilalq wrote: 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…

This is a good list.

One to add to the list is that IAM conditions[0] are extremely powerful but there's no good way to know which conditions to use in which scenario and troubleshooting is very difficult.

For instance if you look at the EC2 CreateNetworkInterface action[1] you'll see that there are three possible resources (network-interface (required), security-group (not required), subnet (required)) and each of those resources have several possible condition keys associated.

What's not obvious is which condition keys will be available in any given request. I've run the same CreateNetworkInterface request with the same parameters and IAM role twice in a row and by looking in the "encoded authorization message" that was returned with the failure in each case I found that in one case the resource was a security group while in the other case it was a subnet. Depending on the resource type different condition keys are available in the context. So if you want to allow CreateNetworkInterface but only if the ec2:SecurityGroupID is 'abc' it might or might not work.

An extra challenge is the encoded authorization message is truncated in CloudTrail so if you're using CloudFormation you don't actually get to see what the context was if a call fails. Then you have to find a way to make the same call CloudFormation made using an SDK so you can get the full text of the encoded authorization message.

There's no easy way to just say "try this API call with this role and tell me exactly what the context would be and what part of the IAM policy hits it if any"

0: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_p... 1: https://docs.aws.amazon.com/service-authorization/latest/ref...

Re: IAM Is the Worst

#73

Post by poxrud »

IAM is complicated but it doesn’t have to be, as long as you keep things organized.

- Use AWS Organizations to organize your teams into Organizational Units

- use SCP to limit permissions of the OUs.

- let the OUs create new aws accounts for every project/workload

- now you have permissions and costs organized per project/workload

Don’t be afraid to create many AWS accounts, this is encouraged and considered best practice.

Re: IAM Is the Worst

#75

Post by remram »

belter wrote: post #54
KingMob wrote: post #34

Earlier quoted context omitted.

I really love the trend of simply restating what an article argues against without addressing the actual article's points. I had an exhausting discussion on Reddit about why storing UTC is not always sufficient from commenters who continually proved they hadn't read the article or the rest of the the comments.

What about the trend of creating provocative titles, and writing blogs on the mood of: "Everybody at Google or AWS is an idiot but me"?

It doesn't take anybody there being an idiot for the system to be idiotic, unfortunately.

Re: IAM Is the Worst

#77

Post by eddd-ddde »

pantulis wrote: post #12

I am well aware that identity and access authorisation is complex, and AWS, GCP and Azure desperately needed to add the capability to their portfolio as this is mandatory for enterprise sales which is where the big bucks are. But boy as soon as they started adding IAM they took all the fun out of deploying my personal shit to any cloud.

IAM is just low level primitives, you can always create one role with all privileges and act like it doesn't exist.

Re: IAM Is the Worst

#78

Post by dopylitty »

tootie wrote: post #55
jchw wrote: 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…

I don't run any clouds myself but if I were AWS or whoever I'd think there's a whole lot of ways to make this process more ergonomic without sacrificing functionality. A tool that can report permission failures with a "should we allow this yes/n?" button for admins. A user (real or service) tries to run a cache invalidation, or write a redshift DB or add an IP to a security group and gets a "permission denied". Admin…

This is more or less what the article proposes except the article proposes doing this one time after collecting a full list of actions.

Both that solution and the one in the article miss one point though: If you use the AWS Console at all it makes hundreds of calls to all manners of AWS service in all available regions. Because of this you can't just assume the calls made by a role intended for interactive use over some period are the "correct" privileges for that role because someone just clicking around in the console will generate thousands API calls to many different services.

Re: IAM Is the Worst

#79

Post by throwawaaarrgh »

GCP IAM is the worst. AWS IAM is not nearly as bad.

GCP sucks so bad as a product, that the only way to tell what IAM policies apply to your service account, is to run some kind of analysis query thing exported to a BigTable (which will cost you money).

You'd think you could just go into the console and click on the service account and it'd show you which policies are linked to roles are linked to your service account? That would make sense, and be convenient. But this is Google we're talking about. Engineering principles will always trump customer experience.

It's much worse than that of course. The default roles give too many permissions, for nearly anything you want to do. Often you are limited by what you can control, to only at an Org level, or Folder, or Project. Yet making a custom role is often difficult, leaving you to usually just slap on the default roles, making your resources insecure. Much of the time, a user must have an Admin-level permission over all VMs in order to SSH into them with GCP creds. Kind of defeating the purpose of having IAM to begin with.

I think the only reason we haven't heard of more GCP accounts getting compromised due to the shitty default policies is, thankfully, GCP has few customers.

Re: IAM Is the Worst

#80

Post by tetha »

dopylitty wrote: post #72
bilalq wrote: 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…

This is a good list. One to add to the list is that IAM conditions[0] are extremely powerful but there's no good way to know which conditions to use in which scenario and troubleshooting is very difficult. For instance if you look at the EC2 CreateNetworkInterface action[1] you'll see that there are three possible resources (network-interface (required), security-group (not required), subnet (required)) and each of t…

Something similar recently tripped me up: Some parts of AWS IAM are extremely detailed and you can create insanely specific policies allowing very precise control (almost to a fault). Other parts are very broad and unspecific.

For example, I recently needed to allow some EC2 instances to push a private IP around between those. I would have assumed I can create some policy along the lines of "Yeah, VMs with this role can push 10.20.30.40 around between their network interfaces". I haven't been able to find any way to restrict these IP addresses, so now I have the smallest policy I could create: "This role can assign fuck-any internal IPs to these interfaces, let's hope for the best." Doesn't really feel the greatest.

Post reply on HN