GitLab 13.3.2 CE与EKS集成时AWS认证失败求助

我之前帮朋友排查过类似的GitLab和EKS集成问题，422状态码本质是请求无法被服务器处理，通常和配置不匹配、权限错误或者参数格式问题有关。结合你给出的操作步骤和IAM策略，这里有几个重点排查方向：

1. 修正IAM策略里的大小写错误 #

你的策略里有个明显的问题：ec2:createTags的Action名称是小写的，而AWS的IAM Action是严格区分大小写的，正确的写法应该是ec2:CreateTags。这个错误会导致该权限无效，可能触发GitLab的权限校验失败，返回422。

修正后的策略片段：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        // ... 其他权限保持不变
        "ec2:CreateTags", // 这里改成大写开头
        // ... 其他权限保持不变
      ],
      "Resource": "*"
    }
  ]
}

2. 检查IAM角色的信任关系配置 #

很多人在这里容易搞混参数，一定要确保：

• 可信实体的AWS账号ID是GitLab官方的AWS账号ID（不是你自己的AWS账号ID），这个ID在GitLab项目的Kubernetes集成页面会明确给出
• External ID必须和GitLab项目里提供的完全一致，不能有空格、大小写错误或者字符缺失
• 信任策略里必须包含sts:AssumeRole的Action，示例信任策略如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::GITLAB_OFFICIAL_ACCOUNT_ID:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "YOUR_PROJECT_UNIQUE_EXTERNAL_ID"
        }
      }
    }
  ]
}

3. 验证GitLab侧的AWS密钥权限 #

你在GitLab Admin Area配置的Access Key和Secret Key对应的IAM用户，必须拥有假设该EKS角色的权限。给这个用户附加以下策略：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/YOUR_CREATED_EKS_ROLE_NAME"
    }
  ]
}

4. 用AWS CLI测试角色可访问性 #

为了排除AWS侧的配置问题，你可以用AWS CLI执行以下命令，模拟GitLab的请求：

aws sts assume-role --role-arn "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/YOUR_EKS_ROLE" --role-session-name "gitlab-test" --external-id "YOUR_PROJECT_EXTERNAL_ID"

• 如果命令成功返回临时凭证，说明AWS侧配置没问题，问题可能出在GitLab本身
• 如果命令失败，根据错误提示修正（比如InvalidExternalID说明ID不匹配，AccessDenied说明权限不足）

5. 考虑GitLab版本兼容性 #

你使用的GitLab 13.3.2 CE是2020年的旧版本，可能存在已知的EKS集成bug。如果上述步骤都无法解决问题，可以尝试升级到13.x系列的最新补丁版本，或者更高的稳定版本（比如14.x），新版本通常会修复这类集成问题。

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