Create least privilege IAM policy for a resource or module

[joepindar]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

As a security specialist, I want my Terraform plans to run with the minimum set of IAM privileges. However, it is not clear which AWS IAM actions are required by a Terraform resource or module. The current solutions to this problem are:

• read the code to identify which API calls are used and set the related IAM actions (requires a detailed understanding of code)
• apply the Terraform plan and use error messages to add IAM actions incrementally (most common solution... but CloudFront deployments - argh)
• allow all IAM actions for a given service (not secure)

This feature request is to create a process or method to generate the set of least privilege IAM actions that are required to apply the Terraform plan successfully.

New or Affected Resource(s)

All resources will be impacted. A potential initial solution would be to automatically generate documentation of the IAM actions required for each resource, and add as a section to the Terraform documentation. Future iterations would then automate the IAM policy generation.

[matthiasr]

I would also be interested in the least privilege policy to create a plan. We have projects shared across teams, where non-infrastructure teams "only" need enough access to modify specific resources, but they do need enough access to terraform plan.

We currently use the second approach, and in this case it is especially painful because someone with enough privileges to use a new kind of resource can inadvertently break planning for many others without noticing.

[kunickiaj]

Would love to hear what folks' current strategies are outside of the ones mentioned by OP as those are all pretty painful.

I've been using Cloudtrail logs from a user/role that has fairly high privileges as a bit of a flight recorder. Then querying those logs with Athena to list all of the permissions invoked for an apply+destroy.

I've found this to capture many but not all of them for some reason but does give a pretty good starting point.

Example query:

select distinct eventname, eventsource, eventtype, additionaleventdata, resources, requestparameters, useridentity.arn
from cloudtrail_logs
where 1 = 1
and account = 'xxxxxx'
and region = 'yyyyy'
and year = '2020'
and eventtime > '2020-08-18'
and useridentity.arn LIKE 'arn:aws:sts::<accountid>:assumed-role/TF-xyz/%'

Throw this into a spreadsheet and you can do some auto grouping to show you the services and actions invoked as well as some details of the resource ARNs in some cases.

I'm surprised I don't see more tools around this -- so maybe a good side project to develop a cloudtrail-based flight recorder + policy generator.

[flosell]

There are some tools that do things similar to what @kunickiaj describes, one of them my own (shameless plug):

• https://github.com/flosell/trailscraper
• https://github.com/duo-labs/cloudtracker

Being a heavy terraform user, my trigger to start building trailscraper was specifically because I couldn't find a way to figure out which permissions were necessary from terraform itself.
Having worked with many teams who were just adopting IaC practices, IAM is often their biggest struggle: they either spend countless hours figuring out a least-privilege policy by trial-and-error or give up and attach AdministratorAccess. Obviously, neither of those is great so anything terraform can do to improve this situation (even by a tiny bit) will be a huge improvement.

[tomasbackman]

Yes very much agreeing with the need of this! I will try out the tools linked above, while hoping that we will get resources that can show/return what services they actually correspond to in AWS and what permissions they need. So that modules could automatically add all resource needs together as some "module requirements" list or similar that easily can be checked against etc.

[paultyng]

Just wanted to add a pointer to this issue as the ability to know the total list of resource/data sources in a configuration could help in this regard (even though it wouldn't be able to limit based on the specifics of those resources): hashicorp/terraform#25568

[flosell]

Here's an interesting approach that might help us here:
iamlive uses AWS SDKs' Client Side Monitoring feature to collect API calls made and translates them into IAM policies.

This tool could be an alternative to the tools mentioned above for people who just want to record what IAM permissions are necessary for their specific terraform project.
More interestingly though, we could try embedding this approach in the providers' acceptance tests to autogenerate documentation about which IAM actions are used:

• Start CSM
• Run acceptance tests for a resource
• Stop CSM and use recorded activity to generate docs for this resource

It'd probably be slightly more complicated if acceptance tests need multiple different resources (e.g. to set up preconditions for the unit under test) but that might be a solvable problem.

Happy to look into this more if folks are interested.

Other resources that might be interesting:
The same author is also working on a lower-level tool that maps AWS SDK actions to IAM Actions.

[confuser]

Just ran into this scenario and required some trial/error to figure out the right permissions. Would be great to start adding necessary permissions to the docs site (after import sections?), perhaps in an iterative fashion?

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!