mirror of
https://github.com/awslabs/iam-policy-autopilot.git
synced 2026-04-25 16:05:58 +03:00
[GH-ISSUE #56] Terraform Language Support #138
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/iam-policy-autopilot#138
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @krockpot on GitHub (Dec 5, 2025).
Original GitHub issue: https://github.com/awslabs/iam-policy-autopilot/issues/56
In addition to the currently supported languages/SDKs, it would be great to have support for the Terraform provider.
I see two potential use cases /tool calls there:
@mschlaipfer commented on GitHub (Dec 5, 2025):
Hey @krockpot thanks for cutting us the issue. For 1., I see a path to supporting Terraform scripts by building a model from the AWS Terraform provider implementation, which maps resources to the AWS operations invoked.
Currently, we don't have exhaustive coverage of FAS operations--especially for control plane operations used in resource provisioning. While we are working on improving our coverage, we would miss permissions for operations called transitively via FAS. Do you think adding support would be useful regardless of this restriction?
Could you expand on 2.? IIUC, you would like to have a way to describe the operations your code performs on a resource and generate policies for/from that? Let me start with saying that we currently do not use resource information for policy generation. We might be able to provide a way to "describe the operations" and generate policies from that, though.
To elaborate: Internally, policy generation works in 3 phases:
We currently only provide an API (MCP command) which performs all 3 phases, but we could think about exposing an API which bypasses the first phase, and starts from enrichment (here). What do you think?
@krockpot commented on GitHub (Dec 5, 2025):
My core use case is 1 -- so I'm fine to scope out the 2nd piece or file it as a separate issue, it was more just an idea I had.
Yes I'd find value even with partial support, having a first pass even if it misses some things would be great.
And yes what you mention about skipping the extraction and going straight to enrichment is roughly what I had in mind, just a way to "support" codebases that aren't in supported languages yet (e.g. i could have a coding agent summarize my API calls and feed that into the enrichment phase, alongside the TF for the resources used by that code).
@weibenz1 commented on GitHub (Dec 9, 2025):
Just to throw an idea out here - once we have TF language support, we can also offer IPA backed terraform provider, which automatically inject policy construct as part of
tf planfor example.@Dianayin422 commented on GitHub (Feb 6, 2026):
Hi @krockpot . I’m Diana Yin, the product manager for IAM Policy Autopilot. I know you’ve probably connected with our team already, but if you have more feedback and would like to talk more, feel free to email me at dianayin@amazon.com and we can set up a time. I'd love to know how to make this product more helpful for you. Thanks!