Azure DevOps双流水线共享Terraform S3状态文件遇403权限问题求助

以下是针对你的问题的排查和解决步骤：

• 确认流水线的AWS身份一致性
  在第二个流水线的terraform init步骤前，添加命令aws sts get-caller-identity，打印当前使用的AWS身份信息，和第一个流水线的输出对比，确保两个流水线实际使用的是同一IAM实体，避免凭证未正确注入流水线环境。

• 检查Terraform状态文件的存储权限（以S3 backend为例）

  • 若状态文件存储在S3桶中，直接查看该对象的ACL权限，确认对应IAM实体拥有s3:GetObject、s3:PutObject、s3:DeleteObject权限；同时检查S3桶策略，是否存在Deny规则限制了这些操作。
  • 即使移除了encrypt = true配置，若状态文件本身是通过KMS加密存储的，仍需确保IAM实体拥有对应KMS密钥的kms:Decrypt、kms:Encrypt权限，检查KMS密钥的权限策略是否包含该实体。

• 验证Terraform backend配置的完全一致性
  确保两个流水线的backend配置（包括S3桶名、区域、状态文件密钥路径、是否启用DynamoDB状态锁等）完全一致。若启用了DynamoDB锁表，需同步确认该表的IAM权限是否允许对应实体进行dynamodb:GetItem、dynamodb:PutItem、dynamodb:DeleteItem操作。

• 排查Agent环境变量差异
  在流水线中添加printenv | grep AWS命令，打印所有AWS相关环境变量，和本地执行时的环境变量对比，排除AWS_PROFILE、AWS_REGION等变量被意外覆盖导致的配置偏差。

• 固定Terraform版本
  确认两个流水线使用的Terraform版本完全一致（第一个升级到的13.x具体版本），避免版本不兼容导致的隐性状态访问问题。可在流水线中通过tfenv固定版本，比如：

  tfenv install 0.13.7 && tfenv use 0.13.7
  

• 检查IAM权限边界与服务控制策略
  若AWS账号启用了IAM权限边界或组织级服务控制策略（SCP），确认这些策略没有限制对应IAM实体访问S3、KMS或DynamoDB的权限。

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