If your application uses some of the AWS services, then it needs correct IAM permissions. For example, to read and write objects to S3 bucket, your app needs correct policy to do that. There are couple of ways to create this policy.
One way is to just give your application full access to your AWS resources. Don’t do that, ever.
Another way is to follow the least privilege principle and craft a very tight policy that only allows what needs to be allowed. But how do you create such a policy without losing your mind? In this article, we will explore some options.
AWS IAM Access Analyser
The first way is a native way, via the built-in policy generation.
- Just go to the IAM role
- Scroll down to the Generate policy button
- Select which time period do you want to analyze
- Select which CloudTrail from which reason you want to analyze
- Create new IAM role that will perform analysis
- and Submit
Then, after a couple of minutes and if the S3 bucket with your CloudTrail events allows the newly created IAM role to access it, AWS Console will offer you a generated policy. You can then adjust this policy with particular resources your application needs to access.
There are two problems with the Access Analyser:
First problem is that you need to properly configure CloudTrail and S3 bucket, and then still do extra configuration on Access Analyser side to get the policy. This is not a big deal if your company has this bits and pieces in place, but if you are new to AWS, then the steps I just told you can be very confusing.
The second problem is that the generate policy is no good. It does not narrow down the permissions to the resources that your IAM Role tried to access, and from our experience, it does not even include some of the permissions in it - probably because the role already has another policy attached.
For example, mkdev’s background job processing Lambda Function accesses SQS every few seconds, and yet Access Analyser does not even think about suggestions any SQS permissions.
AWS CSM and ActionHero
Another option is to use some open source tool. Every AWS SDK supports something called “Client Side Monitoring”. What it means is that every time your application tries to access AWS APIs, AWS SDK will send some metrics about these requests to a monitoring endpoint of your choice.
There is a tiny open source utility called ActionHero that makes use of the Client Side Monitoring feature. It receives the metrics that AWS SDK sends and the logs API actions.
For example, I’ve added ActionHero as a sidecar to mkdev ECS Tasks. Now, when I inspect the logs of the ActionHero container, I can see that my application tries to access SQS and S3.
Same as with IAM Access Analyser, I don’t know which particular resources my application tries to access - I only have a list of API actions. But ActionHero is a bit simpler and faster way to obtain the same information.
Conclusion
To conclude, even though there are some relatively simple ways to automate generation of least-privilege IAM policies, it’s still a bit of a hassle every time. Another approach could be starting without any policies and just deduct the permissions from access denied errors from AWS APIs - but this also has it’s limitations, and neither it’s particularly convenient.
Let us all hope that eventually built in IAM Policy Generator will achieve some higher level of decency.
Here's the same article in video form for your convenience:
.
Top comments (0)