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

Question

我有一个针对 AWS 上的部署的 Terraform 配置。 它适用于使用有权执行任何操作的 IAM 用户（即{actions: ["*"], resources: ["*"]} 。

为了实现此 Terraform 配置应用的自动化，我想确定最初应用配置和影响后续更改所需的最小权限集。 我特别想避免在策略中给予过于宽泛的权限，例如{actions: ["s3:*"], resources: ["*"]} 。

到目前为止，我只是在运行terraform apply直到出现错误。 我查看输出或 terraform 日志输出以查看失败的 API 调用，然后将其添加到部署用户策略中。 EC2 和 S3 特别令人沮丧，因为操作的名称似乎不一定与 API 方法名称一致。 我花了几个小时来用简单的方法来判断我走了多远。

有没有更有效的方法来做到这一点？

如果 Terraform 告诉我我需要什么样的权限/操作，那就太好了，但这是最好留给 Hashicorp 的产品增强功能。

Answer 1

这是另一种方法，类似于上面所说的，但没有进入 CloudTrail -

1. 向您的 IAM 用户授予完全权限。
2. 运行TF_LOG=trace terraform apply --auto-approve &> log.log
3. 运行cat log.log | grep "DEBUG: Request" cat log.log | grep "DEBUG: Request"

您将获得所有使用的 AWS 操作的列表。

Answer 2

编辑 2022 年 2 月：使用 iamlive 和客户端监控有更好的方法。 请看我的另一个回答。

因为我猜没有完美的解决方案，所以把这个答案当作我头脑风暴的结果。 至少对于初始权限设置，我可以想象以下内容：

首先允许所有内容，然后处理 CloudTrail 日志以查看在terraform apply / destroy循环中进行了哪些 API 调用。

之后，您更新 IAM 策略以准确包含这些调用。

Answer 3

虽然我仍然相信这种超级严格的政策将是一个持续的痛苦并且可能会扼杀生产力（但可能取决于项目），但现在有一个工具可以做到这一点。

iamlive使用 AWS 开发工具包的客户端监控功能根据执行的 API 调用创建最小策略。 由于 Terraform 使用 AWS 开发工具包，这也适用于此。

与我之前（并接受）的答案相反，iamlive 甚至应该正确执行实际的 IAM 操作，这些操作不一定与 API 调用 1:1 匹配（并且将由 CloudTrail 记录）。

Answer 4

我遵循的有效方式。

我的处理方式是，首先允许该服务的所有权限 (*)，然后在不需要的情况下拒绝其中的一些权限。

例如

{
    "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": "*"
        }
    ]
}

如果不需要 terraform 或您的公司不使用某些 aws 服务，您可以在拒绝会话中轻松调整列表。

Answer 5

最低权限的跟踪现在由 AWS 自己提供。 https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-活动/ 。

如果您想对最小可行权限原则挑剔，您可以使用 CloudFormation StackSets 以最小权限部署不同的角色，因此 Terraform 可以通过不同的提供者在每个模块调用中承担它们，即如果您有一个部署 ASG、LB 的模块和 EC2 实例，然后：

• 将这些操作包含在工作负载所在的角色中
• 添加一个承担该角色的 terraform aws provider 块
• 在模块调用中使用该提供程序块。

负担是管理可能相当多的 Terraform 角色，但正如我所说，如果您想挑剔或者您有客户要求缩小 Terraform 用户的权限。

您还可以下载最近 X 天（最多 90 天）的 CloudTrail 事件历史记录并运行以下命令：

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

回声是由于从 CloudTrail 的页面下载时文件太大和缩小（未知原因）。 你可以在下面看到它：

> 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

作为之前建议的TF_LOG=trace / iamlive / CloudTrail 方法的补充，还请注意，要捕获管理配置（创建/更新/删除资源）所需的一组完整操作，需要实际应用三个配置：

1. 原始之一，捕获创建资源所需的操作。
2. 使用尽可能多的资源参数进行变异，以捕获更新资源所需的操作。
3. 清空一个（最后应用）或terraform destroy以捕获删除资源所需的操作。

虽然配置 1 和 3 很常见，但配置 2 有时会被忽略，而且准备起来可能很乏味。 没有它，Terraform 将无法应用修改资源的更改，而不是删除和重新创建它们。

Answer 7

这是AvnerSo 答案的扩展：

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

此命令输出 Terraform 记录的每个唯一 AWS 请求。

1. "(?<=DEBUG: Request )[^ ]*"模式执行否定先行查找匹配后的第一个单词。
2. -o标志仅在输出中显示匹配项。
3. sort -u从列表中选择唯一值并对它们进行排序。

Answer 8

除了前面的答案之外的另一个选择是：

• 授予广泛的权限"s3:*", ...如前所述
• 检查 AWS 控制台中的AWS Access Advisor选项卡以获取已使用的权限，然后相应地削减您的权限

Answer 9

您尝试的方法在云技术中有点不寻常。 您可以使用 EC2 IAM 配置文件在 EC2 实例上运行 terraform，而不是为运行 API 调用的 terraform 用户提供细粒度控制，该配置文件允许实例本身使用正确的 AWS 服务权限集调用 API。

每次调用都针对特定的 API 端点。 如果您推送更新，则在应用期间应用的某些 terraform 操作会有所不同。 您还需要知道在资源更新到位的修改操作期间会发生什么。

与其将 API 密钥限制为特定的细节，不如让它有更多的回旋余地，如果它需要创建和销毁 EC2，让它拥有 EC2 完整权限，也许有条件限制到帐户级别或 VPC。