确定 Terraform 配置所需的最低 AWS 权限的最有效方法是什么？

Question

I have a Terraform configuration targeting deployment on AWS. It applies beautifully when using an IAM user that has permission to do anything (ie {actions: ["*"], resources: ["*"]} .

In pursuit of automating the application of this Terraform configuration, I want to determine the minimum set of permissions necessary to apply the configuration initially and effect subsequent changes. I specifically want to avoid giving overbroad permissions in policy, eg {actions: ["s3:*"], resources: ["*"]} .

So far, I'm simply running terraform apply until an error occurs. I look at the output or at the terraform log output to see what API call failed and then add it to the deployment user policy. EC2 and S3 are particularly frustrating because the name of the actions seems to not necessarily align with the API method name. I'm several hours into this with easy way to tell how far long I am.

Is there a more efficient way to do this?

It'd be really nice if Terraform advised me what permission/action I need but that's a product enhancement best left to Hashicorp.

Answer 1

Here is another approach, similar to what was said above, but without getting into CloudTrail -

1. Give full permissions to your IAM user.
2. Run TF_LOG=trace terraform apply --auto-approve &> log.log
3. Run cat log.log | grep "DEBUG: Request" cat log.log | grep "DEBUG: Request"

You will get a list of all AWS Actions used.

Answer 2

EDIT Feb 2022: there is a better way using iamlive and client side monitoring. Please see my other answer.

As I guess that there's no perfect solution, treat this answer a bit as result of my brain storming. At least for the initial permission setup, I could imagine the following:

Allow everything first and then process the CloudTrail logs to see, which API calls were made in a terraform apply / destroy cycle.

Afterwards, you update the IAM policy to include exactly these calls.

Answer 3

While I still believe that such super strict policy will be a continuous pain and likely kill productivity (but might depend on the project), there is now a tool for this.

iamlive uses the Client Side Monitoring feature of the AWS SDK to create a minimal policy based on the executed API calls. As Terraform uses the AWS SDK, this works here as well.

In contrast to my previous (and accepted) answer, iamlive should even get the actual IAM actions right, which not necessarily match the API calls 1:1 (and which would be logged by CloudTrail).

Answer 4

Efficient way I followed.

The way I deal with is, allow all permissions (*) for that service first, then deny some of them if not required.

For example

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSpecifics",
            "Action": [
                "ec2:*",
                "rds:*",
                "s3:*",
                "sns:*",
                "sqs:*",
                "iam:*",
                "elasticloadbalancing:*",
                "autoscaling:*",
                "cloudwatch:*",
                "cloudfront:*",
                "route53:*",
                "ecr:*",
                "logs:*",
                "ecs:*",
                "application-autoscaling:*",
                "logs:*",
                "events:*",
                "elasticache:*",
                "es:*",
                "kms:*",
                "dynamodb:*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Sid": "DenySpecifics",
            "Action": [
                "iam:*User*",
                "iam:*Login*",
                "iam:*Group*",
                "iam:*Provider*",
                "aws-portal:*",
                "budgets:*",
                "config:*",
                "directconnect:*",
                "aws-marketplace:*",
                "aws-marketplace-management:*",
                "ec2:*ReservedInstances*"
            ],
            "Effect": "Deny",
            "Resource": "*"
        }
    ]
}

You can easily adjust the list in Deny session, if terraform doesn't need or your company doesn't use some aws services.

Answer 5

The tracking of minimum permissions is now provided by AWS itself. https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/ .

If you wanted to be picky about the minimum viable permission principle, you could use CloudFormation StackSets to deploy different roles with minimum permissions, so Terraform could assume them on each module call via different providers, ie if you have a module that deploys ASGs, LBs and EC2 instances, then:

• include those actions in a role where the workload lives
• add an terraform aws provider block that assumes that role
• use that provider block within the module call.

The burden is to manage possibly quite a few terraform roles, but as I said, if you want to be picky or you have customer requirements to shrink down terraform user's permissions.

You could also download the CloudTrail event history for the last X days (up to 90) and run the following:

cat event_history.json <(echo "]}") | jq '[.Records[] | .eventName] | unique'

The echo thing is due to the file being too big and shrunk (unknown reason) when downloaded from CloudTrail's page. You can see it below:

> jsonlint event_history.json
Error: Parse error on line 1:
...iam.amazonaws.com"}}
-----------------------^
Expecting ',', ']', got 'EOF'
    at Object.parseError (/usr/local/Cellar/jsonlint/1.6.0/libexec/lib/node_modules/jsonlint/lib/jsonlint.js:55:11)
    at Object.parse (/usr/local/Cellar/jsonlint/1.6.0/libexec/lib/node_modules/jsonlint/lib/jsonlint.js:132:22)
    at parse (/usr/local/Cellar/jsonlint/1.6.0/libexec/lib/node_modules/jsonlint/lib/cli.js:82:14)
    at main (/usr/local/Cellar/jsonlint/1.6.0/libexec/lib/node_modules/jsonlint/lib/cli.js:136:14)
    at Object.<anonymous> (/usr/local/Cellar/jsonlint/1.6.0/libexec/lib/node_modules/jsonlint/lib/cli.js:178:1)
    at Module._compile (node:internal/modules/cjs/loader:1097:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1149:10)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)

Answer 6

As an addition to either of TF_LOG=trace / iamlive / CloudTrail approaches suggested before, please also note that to capture a complete set of actions required to manage a configuration (create/update/delete resources) one would need to actually apply three configurations:

1. Original one, to capture actions required to create resources.
2. Mutated one with as many resource arguments changed as possible, to capture actions required to update resources inplace.
3. Empty one (applied last) or terraform destroy to capture actions required to delete resources.

While configurations 1 and 3 are common to consider, configuration 2 is sometimes overlooked and it can be a tedious one to prepare. Without it Terraform will fail to apply changes that modify resources instead of deleting and recreating them.

Answer 7

Here is an extension on AvnerSo's answer :

cat log.log | ack -o "(?<=DEBUG: Request )[^ ]*" | sort -u

This command outputs every unique AWS request that Terraform has logged.

1. The "(?<=DEBUG: Request )[^ ]*" pattern performs a negative lookahead to find the first word after the match.
2. The -o flag only shows the match in the output.
3. sort -u selects the unique values from the list and sorts them.

Answer 8

Another option in addition to the previous answers is:

• give broad permissions "s3:*", ... as explained earlier
• Check the AWS Access Advisor tab in the AWS console for used permission and then trim down your permissions accordingly

Answer 9

The method you are attempting is a bit unusual in cloud technology. Instead of giving fine grained control to the terraform user running the API calls, you could run terraform on an EC2 instance with an EC2 IAM profile that allows the instance itself to call the API's with the correct set of AWS service permissions.

Each call is made to a specific API endpoint. Some terraform operations applied during a apply would be different if you pushed an update. You also need to know what happens during a modify operation where a resource is updated in place.

Instead of restricting that API key to specifics, let it have more leeway, if it needs to create and destroy EC2, let it have EC2 full perms maybe with conditionals to restrict to account level or VPC.