I should also mention that the IAM authoring aspect of this tool is more mature than the policy analysis feature.
In CI/CD, if you are using Terraform, I suggest using Open Policy Agent for blocking access to certain resources by evaluating a Terraform plan. I suppose it's also possible to use OPA to evaluate the JSON output of a policy_sentry YML file.
Hope this helps.
I haven't used it in production. It uses an even-more-baroque syntax than terraform's HCL dialect, and using it kind of assumes that all your modifications go through terraform.
You also have the problem that not all actions are recorded by CloudTrail (ex. cloudwatch:putmetricdata).
Now, I think that it's possible this tool could be extended to support that. For example... you could use Amazon Athena to query CloudTrail logs from an S3 bucket, and then query the logs to determine which principals touch which ARNs. For each IAM principal, create a list of ARNs. For each ARN, plug that ARN into a policy_sentry yml file, and determine the CRUD level based on a lazy comparison of the action listed in the cloudtrail log vs the reosurce ARN. And then run the policy_sentry yml file to generate an IAM policy that would have worked. But that's just my idea... actual implementation of that would be a bigger effort than what I could take on myself.
If you are interested in that kind of feature, please comment and I'll point this out to some other engineers who will be contributing to this tool as well.
Integration with cloudtrail sort of lands on teams, they suddenly get told it's a priority for that quarter, they scramble around like mad, shove a fresh-out-of-college hire on it with little oversight, and you get what you get...
With that being said, it is a wicked tool and you should try it out.
I hope to build this into our roadmap.
Some people claim it's the wrong way, because it's another abstraction between a CFN-template and the CFN-engine (more moving parts, etc) and using a markup language that restricts you a bit, makes things more manageable.
Essentially: Even when Infrastructure as Code exists, IAC developers can still make security mistakes. Our goal with this tool was to automate the process (it is way faster to build policies with this), and by default, restrict actions according to resource ARNs. I haven't seen any other tool do that to this degree, although I would be pleasantly surprised to learn about any that do.
Edit: Not sure why HN is blocking out the wildcard character.
Some of the higher level constructs apply smart rules. Eg adding a load balancer target adds restricted access rules.
It's still hard to know what's been created and how everything is connected.
I made a graph visualization tool that live updates from a Cloudformation file. It solved all my visibility and understanding issues. I plan to release it soon.
Or rather, I didn't without going Readme > Wiki > User Guide > something else - a YAML example should really be in the readme, this looks great!
Netflix released one two years ago: https://medium.com/netflix-techblog/introducing-aardvark-and...
How does it differ from `aws-iam-generator` released by AWS themselves?
aws-iam-generator still requires you to write the actual policy templates from scratch, and then they allow you to re-use those policy templates.
Consider the JSON under this area of their README: https://github.com/awslabs/aws-iam-generator#managed-policie...
It's essentially a method for managing their policies as code - but it doesn't make those policies restricted to certain resources, unless you configure it that way. Using `policy_sentry --write-policy --crud`, you have to supply a file with resource ARNs, and it will write the policy for you, rather than supplying a policy file, and hoping the ARNs fit that use case.
Does that make sense?
