kmcquade

+1 on the Service control policies

I haven't used the AWS CDK before. I'm more of a Terraform guy. But at a glance, I don't think it solves the issue with access levels and resource ARNs. You can still create IAM policies that have s3:wildcard, or `service:someaction` against wildcard resources.

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.

Regarding your point on the API logs - there are some blunders on AWS's part that make "policy suggestion" difficult. Behind the scenes right now, is still AWS figuring out what IAM privileges actually correlate to what actions. A simple example of this is the privilege s3:listallmybuckets correlates to the action and subsequent CloudTrail event s3:listbuckets. It is insane to think about, but AWS never kept track of those differences.

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.

In the Terraform use case, that is probably possible if you hack together an analysis of the JSON policy files generated by the Terraform module and then allow/warn/deny based on the results. Alternatively, you could run the IAM analysis portion of this tool after Terraform apply.

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.