多用户Terraform场景下仅允许执行terraform plan的IAM策略权限配置咨询

这个问题其实核心是区分Terraform执行plan和apply时对应的云服务权限差异，结合我在多用户Terraform环境的实践，给你拆解一下配置思路：

简单来说：

• terraform plan本质是只读操作：它会读取远程状态文件、查询当前云资源的实际状态，然后对比生成执行计划，全程不会修改任何资源或状态。
• terraform apply是读写操作：它会根据计划创建/修改/删除云资源，同时更新远程状态文件。

所以给用户B配置权限的核心是：允许所有只读类操作，严格禁止任何会修改资源或状态的写操作。

下面以AWS为例（主流云服务商的配置逻辑类似，可按需调整），分两部分配置：

1. 云服务资源的基础只读权限 #

需要允许所有云资源的查询/读取类动作，同时显式拒绝创建/修改/删除类动作。示例策略如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "s3:Get*",
        "s3:List*",
        "rds:Describe*",
        "lambda:Get*",
        "lambda:List*",
        "iam:Get*",
        "iam:List*"
        // 务必根据你实际用到的云服务，补充对应的只读Action
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "ec2:Create*",
        "ec2:Delete*",
        "ec2:Modify*",
        "s3:Put*",
        "s3:Delete*",
        "rds:Create*",
        "rds:Delete*",
        "lambda:Create*",
        "lambda:Delete*",
        "lambda:Update*",
        "iam:Create*",
        "iam:Delete*",
        "iam:Update*"
        // 对应上面服务的写操作Action，确保覆盖所有可能的修改动作
      ],
      "Resource": "*"
    }
  ]
}

2. Terraform远程状态存储的权限限制 #

如果生产环境用S3+DynamoDB做远程状态存储（强烈建议），需要给用户B配置仅读状态文件+允许状态锁操作的权限：

{
  "Version": "2012-10-17",
  "Statement": [
    // S3状态存储：仅允许读取和列出桶内容，禁止修改/删除状态文件
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-terraform-state-bucket",
        "arn:aws:s3:::your-terraform-state-bucket/*"
      ]
    },
    {
      "Effect": "Deny",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::your-terraform-state-bucket/*"
    },
    // DynamoDB状态锁：允许获取和释放锁（terraform plan也需要锁来避免冲突）
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:DeleteItem"
      ],
      "Resource": "arn:aws:dynamodb:your-region:your-account-id:table/your-terraform-lock-table"
    }
  ]
}

• 最小权限原则：不要用*作为Resource，尽量缩小到具体的资源ARN（比如特定的EC2实例ID、S3桶），减少权限溢出风险。
• 测试验证：配置完成后，让用户B执行terraform plan确认成功，再尝试terraform apply，如果报错权限不足，说明策略生效。
• 工作区隔离：如果用Terraform工作区区分环境（dev/prod），可以给用户B的策略加上工作区对应的资源限制，比如仅允许访问dev工作区的状态文件。
• 避免权限逃逸：有些隐含风险的动作（比如iam:PassRole）如果不需要，也要显式拒绝，防止用户绕过限制。

内容的提问来源于stack exchange，提问作者Tetsuya Saitou