[GH-ISSUE #56] Terraform Language Support #138

Open
opened 2026-03-15 11:46:05 +03:00 by kerem · 4 comments
Owner

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:

  1. Given a workspace, what policy is needed to apply that Terraform.
  2. Given a workspace of my services resources and a description of it's behavior, what policy would cover that (e.g. a weaker version of looking at the code, which could potentially help with adoption for unsupported languages in cases where Terraform is used)
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: 1. Given a workspace, what policy is needed to apply that Terraform. 2. Given a workspace of my services resources and a description of it's behavior, what policy would cover that (e.g. a weaker version of looking at the code, which could potentially help with adoption for unsupported languages in cases where Terraform is used)
Author
Owner

@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:

  1. Operation extraction from source code
  2. Enrichment
  3. Policy generation

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?

<!-- gh-comment-id:3617585430 --> @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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)--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: 1. Operation extraction from source code 2. Enrichment 3. Policy generation 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](https://github.com/awslabs/iam-policy-autopilot/blob/047b11395812048ee127b8681181d2886ce0af09/iam-policy-autopilot-policy-generation/src/enrichment/engine.rs#L42)). What do you think?
Author
Owner

@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).

<!-- gh-comment-id:3617841739 --> @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).
Author
Owner

@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 plan for example.

<!-- gh-comment-id:3633859251 --> @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 plan` for example.
Author
Owner

@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!

<!-- gh-comment-id:3861983177 --> @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!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/iam-policy-autopilot#138
No description provided.