4 ms·
IAM is conceptually straightforward, but it's combinatorial difficult with all the different ways that AWS services interact with it. Support for IAM is also in
by js2 2y ago
IAM is conceptually straightforward, but it's combinatorial difficult with all the different ways that AWS services interact with it. Support for IAM is also inconsistent across services. I'll give a recent example.
I have EC2 Mac instances in an autoscaling group that are running untrusted code. I've "sandboxed" that code by running it as its own user and blocking that user from reaching the IMDS endpoint with a packet filter on the instance so that the untrusted code, in theory, cannot get instance policy credentials. Nonetheless, I'd like to limit the blast radius should the code somehow escape that sandbox. So I want the instance policy as restricted as possible.
One of the things the instances need to do is set tags on themselves. For this, you can use an IAM condition on the ec2 CreateTags action to say "this instance can call CreateTags, but the instance ID has to be the instance itself". This prevents an instance from setting tags on a different instance in the same autoscaling group.
The instances also need to make a few autoscaling API calls, to complete lifecycle actions (CompleteLifecycleAction), and to enable and disable scaling protection (SetInstanceProtection). Here again, I'd like each instance to only be able to make these calls against itself. Unfortunately, there is no condition you can use with the autoscaling API to similarly limit the calls as you can with the ec2 API. The same condition that works with the ec2 API doesn't do anything with the autoscaling API.
Not helping matters, the documentation is very spread about. Just in the use case I describe above, you need to read at least all of these:
https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html https://docs.aws.amazon.com/service-authorization/latest/ref...
https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2autoscaling.html https://docs.aws.amazon.com/service-authorization/latest/ref...
https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-api-permissions.html https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-au...
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policy-structure.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-poli...
https://docs.aws.amazon.com/autoscaling/ec2/userguide/control-access-using-iam.html https://docs.aws.amazon.com/autoscaling/ec2/userguide/contro...
- js2 2y agoBTW, there's no reason I can see that the condition couldn't work in both cases, but apparently this is up to the API/service to implement. The condition for CreateTags is: Condition: StringLike: aws:userid: "*:${ec2:InstanceID}" Documented (sorta) across four(!) pages: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-userid https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_p... https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_p... https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policy-structure.html#ec2-supported-iam-actions-resources https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-poli... https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-actions-as-permissions https://docs.aws.amazon.com/service-authorization/latest/ref...