使用不同角色执行Terraform Plan/Apply时的AWS EKS认证问题

我希望在CI/CD流水线中用只读AWS角色执行terraform plan，再用权限更高的独立读写AWS角色执行生成的plan，以此分离计划/读取与执行/写入操作，提升安全性。但配置EKS时遇到认证问题：plan阶段用只读角色生成EKS认证数据，该角色无EKS访问权限，导致apply阶段复用plan部署Helm Chart失败。

想请教两个核心问题：

1. 在CI/CD流水线中用只读角色运行terraform plan是否属于常规做法？
2. 我是否应该放弃这种谨慎原则，直接用特权读写角色同时执行plan和apply？或者有没有其他方法确保apply阶段使用正确的读写凭证？

相关Terraform代码 #

## Get Reference to Kube Cluster
data "aws_eks_cluster" "cluster" {
  name = var.cluster_name
}

## Get Auth Data
data "aws_eks_cluster_auth" "cluster" {
  name = var.cluster_name
}

## Use Auth Data
provider "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.cluster.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
    token                  = data.aws_eks_cluster_auth.cluster.token
  }
}

Terraform错误信息 #

Error: Kubernetes cluster unreachable: the server has asked for the client to provide credentials

补充说明：我们使用EKS API集群认证模式，且已为读写角色配置管理员IAM访问条目。目前发现给只读角色添加EKS管理员IAM权限可以解决错误，但这违背了角色分离的初衷。

• 只读角色执行plan是常规最佳实践：这种角色分离是基础设施即代码的安全最佳实践之一，能有效降低误操作风险，避免只读阶段意外修改资源，同时符合最小权限原则，不建议直接放弃。

• 解决EKS认证问题的替代方案：

  1. 延迟EKS认证数据生成到apply阶段：调整data "aws_eks_cluster_auth"的调用逻辑，通过Terraform的count/for_each条件判断，或使用terraform apply -var传入动态参数，让认证数据仅在apply阶段用读写角色生成，而非固化到plan文件中。
  2. 给只读角色授予最小EKS权限：如果必须在plan阶段获取集群信息，不要直接给管理员权限，仅授予eks:DescribeCluster（获取端点和CA证书）和eks:GetClusterAuth（生成认证token）的权限，同时确保该角色在EKS集群内无管理员权限，既满足plan需求，又不违反最小权限原则。
  3. 通过变量隔离Helm认证配置：在CI/CD流水线中，plan阶段用只读角色时，将Helm provider的认证配置（如token）设为空或跳过，仅验证集群端点和CA证书的存在；apply阶段切换为读写角色后，再完整配置认证信息并执行部署。
  4. 拆分集群管理与应用部署：把EKS集群创建和Helm Chart部署拆分为两个独立的Terraform模块或流水线阶段。集群模块用读写角色执行，应用部署模块在plan阶段仅读取集群元数据（无需认证token），apply阶段用读写角色生成认证token并完成部署，实现更细粒度的权限分离。

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