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.

https://www.openpolicyagent.org/docs/latest/terraform/ very neat, I hadn't seen opa used in this way before.

Oh yeah it's super powerful. And it's not vendor-dependent like Sentinel & TF Enterprise (although I really love TF Cloud).

Here's an example of using OPA + Conftest with Terraform that you might be interested in: https://github.com/kmcquade/conftest-terraform-multifolder-p...

Hashicorp has a tool/framework for this, Sentinel https://www.hashicorp.com/sentinel/

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.

Yep. Sentinel is for paid customers only, so it has to go through Terraform enterprise.

Not sure I understand your question fully but if this doesn't support it you can tack on permission boundaries if you wish to apply a permission blacklist to a specific role. If it's account wide you can apply service control policies via AWS organizations.

+1 on the Service control policies