Terraform+Helm部署EKS负载均衡控制器CI/CD认证失败求助

核心原因 #

CI/CD环境与本地环境在权限配置、工具依赖、环境变量上存在差异，导致Helm Provider无法获取EKS集群的有效认证凭证，进而出现连接失败。

具体排查与修复步骤 #

1. 校验CI/CD环境的AWS权限 #

• 确保CI/CD Runner使用的AWS身份（IAM角色/Access Key）拥有eks:DescribeCluster和sts:GetCallerIdentity权限，这是aws eks get-token命令正常执行的基础。
• 若采用GitLab CI的OIDC角色关联，需确认角色信任策略已正确配置，允许GitLab的OIDC身份访问。

2. 修复Helm Provider的exec认证配置 #

原配置中aws eks get-token的参数存在不合理之处，且CI环境需显式指定AWS区域，调整后的配置如下：

provider "helm" {
  kubernetes {
    host                   = aws_eks_cluster.La-Production-EKS.endpoint
    cluster_ca_certificate = base64decode(aws_eks_cluster.La-Production-EKS.certificate_authority[0].data)
    exec {
      api_version = "client.authentication.k8s.io/v1beta1"
      args        = [
        "eks", "get-token",
        "--cluster-name", aws_eks_cluster.La-Production-EKS.name,
        "--region", var.aws_region # 显式指定集群所在区域
      ]
      command = "aws"
      # 可选：若CI环境需指定AWS配置文件，可取消注释
      # env = {
      #   AWS_PROFILE = "ci-profile"
      # }
    }
  }
}

注意：将原配置中的aws_eks_cluster.La-Production-EKS.id改为name，因为get-token命令需要的是集群名称而非ARN。

3. 验证KUBECONFIG方式的配置有效性 #

若使用config_path方式连接，需确认：

• $PATH_KUBECONFIG指向的文件在CI Runner中真实存在，且文件内容为有效的EKS kubeconfig（可提前通过aws eks update-kubeconfig生成）。
• 在terraform plan前添加验证步骤：kubectl --kubeconfig=$PATH_KUBECONFIG get nodes，确认kubectl能通过该配置访问集群。

4. 检查CI环境的工具版本兼容性 #

• 确保CI环境中的aws-cli为2.x版本，旧版CLI可能不支持eks get-token的v1beta1 API版本。
• 对齐CI与本地环境的Terraform、Helm Provider版本，避免因版本差异导致的兼容性问题。

5. 调试认证过程定位问题 #

在CI Pipeline中添加调试步骤，输出关键信息：

# 检查当前AWS身份
aws sts get-caller-identity
# 手动尝试获取集群token
aws eks get-token --cluster-name <你的集群名称> --region <集群区域>
# 输出AWS相关环境变量
echo $AWS_ACCESS_KEY_ID $AWS_SECRET_ACCESS_KEY $AWS_REGION

通过这些输出可快速定位是身份权限、命令参数还是环境变量缺失导致的问题。

内容的提问来源于stack exchange，提问作者Руслан Пилипюк