How to determine the AWS IAM policy permissions needed to use AWS Terraform Resources?

Question

I need to determine exactly the bare minimum AWS IAM permissions needed to create, update and delete several Terraform AWS resources used by some of our terraform templates. This is so we can provide an exact list of permissions needed by our customers to run our terraform templates.

My normal AWS user is a full admin, so the access advisor isn't too helpful for tracking down this task. Instead of creating a new user with no permissions and gradually adding more in until I can run terraform, I wanted to know if there was a better way of finding the needed requirements?

Is there an online AWS resource detailing the bare minimum permissions needed to run CRUD operations on specific resource types? Is there a document in terraform that shows this? Is there a way to have the access advisor show the specific permissions used in operations when I have general * admin rules applied on a user?

For reference here is the list of terraform resources I need to find permission info about:

aws_vpc
aws_iam_instance_profile
aws_iam_policy
aws_iam_role
aws_iam_role_policy_attachment
aws_eip
aws_instance
aws_lb_target_group_attachment
aws_network_interface
aws_security_group
aws_internet_gateway
aws_lb
aws_lb_listener
aws_lb_target_group
aws_route
aws_route
aws_route_table_association
aws_subnet
aws_autoscaling_group
aws_launch_configuration

Answer 1

The aws provider is open source. You could go to the plugin and look at the golang code and see what SDK calls are made. Those correspond to aws iam permission actions.

For aws_vpc : https://github.com/terraform-providers/terraform-provider-aws/tree/master/aws/resource_aws_vpc.go

It's tedious, but I don't think such a compiled list exists. But this is a very definitive way to see what calls are being made. It might require maintenance as the provider is updated.

Also, there are likely calls that the provider itself uses, which will also be in the source code.

This isn't necessarily as painstaking as it may sound. I see that the name they give the client session across the whole file is conn . All actions would be accessed as methods on that struct. So I did a quick search for all conn. . Then I use vscode's cmd+shift_l hotkey to multiselect all instances of that. Then I use cmd+alt+rightarrow. That selects all occurances of conn.<method> .

Then I paste into a new file. Use vscode plugin to remove non-unique lines. Then I sort, just because I want to. And I get:

conn.AssociateVpcCidrBlock
conn.CreateVpc
conn.DeleteVpc
conn.DescribeNetworkAcls
conn.DescribeRouteTables
conn.DescribeSecurityGroups
conn.DescribeVpcAttribute
conn.DescribeVpcClassicLink
conn.DescribeVpcClassicLinkDnsSupport
conn.DescribeVpcs
conn.DisableVpcClassicLink
conn.DisableVpcClassicLinkDnsSupport
conn.DisassociateVpcCidrBlock
conn.EnableVpcClassicLink
conn.EnableVpcClassicLinkDnsSupport
conn.ModifyVpcAttribute
conn.ModifyVpcTenancy

As I mentioned, the provider might have some baseline permissions it needs. I went to the provider_test.go file and repeated that method to find these permissions. So these actions should also be added.

conn.DescribeOrganization
conn.DescribeAccountAttributes
conn.DescribeSubnets

---

If you use cloudtrail logs, you better invoke each stage of the CRUD lifecyle of each resource and you might be ok.