Someone has actually been working on a project like this. While not 100% complete it's the best working one I know of. Can definitely relate to the problem being described here, especially when writing IAM policies for terraform deployments.
Probably can’t be open sourced given IP under contracts but I could try to re-write it. There’s some new services in IAM that could be leveraged to make it more accurate and cheaper to use, too.
Thank you for putting this idea in my head! I’ve been trying to get better at expressing infrastructure as code, and one of the big blockers has been how adding new services to e.g. Terraform is tough when you don’t know all their permissions they need (see also https://github.com/hashicorp/terraform/issues/2834 for example).
Using a test AWS environment to stage and then checking CloudTrail to see what was actually called would be a step forward. Having software to extract it would be even better.
You are so right on the SELinux comparison. Of course, in this case, there are way more developers that are required to write them.
Reiterating what was mentioned in the thread - the best way to avoid this wildcard situation and make it easier for developers is to use Policy Sentry[0]
Thought I’d mention this for those who read the title and the comments instead of clicking on the tools. This will solve most of your problems with writing IAM policies for machine roles.
PMapper is definitely a great tool. It’s best used in Pentests for validating some privilege escalation paths. It has the benefit of analyzing IAM trust policies, resource based policies, viewing escalation paths in a graph based approach. Very underrated indeed.
Cloudsplaining is faster at creating a more comprehensive report. We realize that there is lots of damage that can be done just by being able to modify Infrastructure, even when your privileges fall short of legit privilege escalation.
Not one step exactly, but it is by far the easiest way to write least privilege IAM policies. Otherwise, it becomes impossible to ensure IAM policies are written securely and at scale. This way, all custom IAM policies are written with the exact same methodology.
> "I'm pretty excited, I've never won a single thing in my life before. And to do it in service of taking down evil patent trolls? This is one of the best days of my life, no joke. I submitted because software patents are garbage and clearly designed to extort money from productive innovators for vague and obvious claims. Also, I was homeless at the time I submitted and was spending all day at the library anyway." — Garrett, San Francisco
Aardvark and Repokid revoke privileges based on AWS Access Advisor, which tells you when certain services have not been used within X amount of days/months. But it only does this for services, not for actions. So the resulting API calls are not very granular.
It does, but some disclaimers:
1. The generated policies have Resources set to all, not to a specific resource ARN
2. It downloads all of the CloudTrail logs. This takes a while. Cloudtracker (https://github.com/duo-labs/cloudtracker) uses Amazon Athena, which is more efficient. In the future, I'd like to see a combined approach between all three of these tools to generate IAM policies based on Cloudtrail logs.
3. It is accurate to the point where there is a 1-to-1 mapping with the IAM actions vs CloudTrail logs. As I mentioned in other comments, since not every IAM Action is logged in CloudTrail and not every CloudTrail action matches IAM Actions, the results are not always accurate.
With that being said, it is a wicked tool and you should try it out.
Thank you! I'm glad to see there's progress on this. I've been holding off putting the infrastructure automation into CI/CD, due to the incredible amount of work it would take to create a least-access policy. Tooling like this will help a lot.
