4 ms·

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 s

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_policies_elements_condition.html https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_p... 1: https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html https://docs.aws.amazon.com/service-authorization/latest/ref...

tetha 3y ago
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.
- belter 3y ago
  { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AssignPrivateIpAddresses", "ec2:UnassignPrivateIpAddresses", "ec2:AttachNetworkInterface", "ec2:DetachNetworkInterface" ], "Resource": "*" } ] }
  - tetha 3y ago
    How does this control the private IP address that can be assigned? How does this stop the VM from just grabbing any IP? There isn't even anything IP-shaped in that policy.
belter 3y ago
> 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?
- dopylitty 3y ago
  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.

tetha 3y ago

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.

belter 3y ago
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AssignPrivateIpAddresses", "ec2:UnassignPrivateIpAddresses", "ec2:AttachNetworkInterface", "ec2:DetachNetworkInterface" ], "Resource": "*" } ] }
- tetha 3y ago
  How does this control the private IP address that can be assigned? How does this stop the VM from just grabbing any IP? There isn't even anything IP-shaped in that policy.

belter 3y ago

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

dopylitty 3y ago
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.