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

81–90 of 102 posts

Re: IAM Is the Worst

#81

Post by belter »

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…

> there's no good way to know which conditions to use in which scenario

A start could be this even if does not address your scenario of calling twice in a row. I will discuss that one further below in the comment.

aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::ACCOUNT:user/Paul --action-names "ec2:CreateNetworkInterface" --context-entries ContextKeyName="ec2:Subnet",ContextKeyValues="subnet-12345678",ContextKeyType=string --resource-arns "arn:aws:ec2:REGION:ACCOUNT:subnet/subnet-12345678" > simulatedIAMOutput.json

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

Well EC2 would process these requests by first verifying subnet-related permissions before moving on to security group permissions. Variations in the error messages could reflect the point at which the request encounters a permission issue?

Re: IAM Is the Worst

#82

Post by belter »

tetha wrote: post #80
dopylitty wrote: post #72

Earlier quoted context omitted.

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…

  {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AssignPrivateIpAddresses",
                "ec2:UnassignPrivateIpAddresses",
                "ec2:AttachNetworkInterface",
                "ec2:DetachNetworkInterface"
            ],
            "Resource": "*"
        }
    ]
}

Re: IAM Is the Worst

#83

Post by AtlasBarfed »

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…

IAM is an excellent example of why from a developer perspective security is "broken".

Some security group at a company will have a "review" of your permissions. Occasionally they will run a "sweep" and yank permissions out from under you.

Instead, here we have an API that the security team can actively manage and PROVIDE A SOLUTION. Should a developer on some project have domain knowledge of IAM to make a perfect bespoke (and it WILL be bespoke) least-permission policy?

No, of course no. that domain knowledge should be a service in any substantive AWS org where they provide it to you, and much more importantly, DEBUG it for you when it doesn't work.

Because here's the deal: IAM may be a bit ugly and have some cruft and evolution, and I believe S3 permissions are another entire headache atop IAM, but this is what an extremely fine grained permissions model looks like: detail hell.

ALL detailed permissions models will look like this. Defining perfect names (by definition coarse grained) to communicate the precise multidimensional n-brane border of a policy is basically impossible.

Here is another issue: in my last job they were obsessed with short-duration tokens and TOTP. Ok great. Hey wait, if I need to run an automated cluster-wide job that will take hours (backup, cleanup, log analysis, etc), what do I do then?

Security team didn't care. Automation? What's that? Just sit there watching the log and manually refresh the keys.

So I end up using a software TOTP generator and hacking it that way. I should not be doing that. It is likely a security hole. The security team should have heard my requirements, accepted them as a necessity (they are) and provided me a solution.

Security should be a solution and service.

Re: IAM Is the Worst

#84

Post by mstipetic »

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…

I gave up trying to reason with it when I attempted to upload a docker image. Turns out I had permissions to upload an image, but not individual layers.

Re: IAM Is the Worst

#85

Post by biimugan »

belter wrote: post #60
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…

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

CloudTrail is almost never useful on its own. So often CloudTrail will tell you something is denied and give you literally no other useful, direct information, especially as you start dealing with SCP-related denials. CloudTrail gives you a pile of metadata and says "here's everything, you figure it out". A mature audit solution would tell me the exact policy and line number that caused the denial and not play these guessing games.

The comment about out-of-the-box policies is true, I suppose, but hard to take seriously. Almost every policy example you encounter in the AWS documentation is insecure by default. They've gotten better over time noting this and pointing to better examples for different use cases. But it's still pretty bad.

Re: IAM Is the Worst

#86

Post by biimugan »

As a side note to all this: Can we please get rid of encoding policy logic in JSON or other proprietary policy languages? I just want Rego, man.

While we're at it, publish these IAM engines as public, open-source projects so that we can write proper unit tests. I don't want to call a policy simulator API.

Re: IAM Is the Worst

#87

Post by aggcefbhtd »

belter wrote: post #67
aggcefbhtd wrote: post #63

Earlier quoted context omitted.

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

I think “IAM makes me feel like a fighter pilot” is a hilarious interpretation of your argument. Love it.

Re: IAM Is the Worst

#88

Post by dopylitty »

belter wrote: post #81
dopylitty wrote: post #72

Earlier quoted context omitted.

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…

> there's no good way to know which conditions to use in which scenario A start could be this even if does not address your scenario of calling twice in a row. I will discuss that one further below in the comment. aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::ACCOUNT:user/Paul --action-names "ec2:CreateNetworkInterface" --context-entries ContextKeyName="ec2:Subnet",ContextKeyValues="subnet-123456…

Policy simulator is indeed a great option except I didn't have access to it at the time because it was disabled via SCP :D

Kidding around though I'll try that if I face a similar issue in the future. It has been improving quite a bit lately.

> Well EC2 would process these requests by first verifying subnet-related permissions before moving on to security group permissions. Variations in the error messages could reflect the point at which the request encounters a permission issue?

I would think the context would be deterministic in that case but I verified calling the API with the same parameters using the same role twice in a row ended up with different 'resource' values in the context. It was almost like under the hood boto3 or something else was changing the order of the parameters in the API call which was changing the way the context was created. I could've put in a support case but had bigger fish to fry.

Re: IAM Is the Worst

#89

Post by belter »

aggcefbhtd wrote: post #87
belter wrote: post #67

Earlier quoted context omitted.

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

I think “IAM makes me feel like a fighter pilot” is a hilarious interpretation of your argument. Love it.

Well the stakes are sometimes as high....

Re: IAM Is the Worst

#90

Post by mannyv »

The main problem with AWS IAM is you have to understand the service, how it works, and what the permissions do to restrict permissions correctly.

But that's true for anything with granular permissions.

Answering "what permissions are needed to perform X" is hard in any context. In AWS it can be overwhelming because AWS is big and interconnected.

Post reply on HN