基于EKS的Gitlab-CI Runner结合AWS IAM角色配置可行性问询

核心是通过**EKS的IAM角色绑定（IRSA）**结合GitLab CI的配置，让不同团队的作业Pod自动假定对应权限的IAM角色，实现AWS账号级别的权限隔离。

1. 为各团队创建隔离的AWS IAM角色 #

• 给每个团队单独创建IAM角色，仅赋予其自身AWS账号内基础设施部署所需的最小权限（比如CloudFormation、EC2、S3等权限，按需配置）。
• 为每个IAM角色配置OIDC信任策略，允许EKS集群中的指定服务账号扮演该角色。策略示例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<AWS账号ID>:oidc-provider/oidc.eks.<区域>.amazonaws.com/id/<EKS集群OIDC ID>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.<区域>.amazonaws.com/id/<EKS集群OIDC ID>:sub": "system:serviceaccount:<GitLab Runner命名空间>:<团队专属服务账号名>",
          "oidc.eks.<区域>.amazonaws.com/id/<EKS集群OIDC ID>:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

• 在EKS中创建对应服务账号，并绑定到上述IAM角色：

eksctl create iamserviceaccount \
  --cluster=<你的EKS集群名> \
  --namespace=<Runner所在命名空间> \
  --name=<团队专属服务账号名> \
  --attach-policy-arn=<对应IAM角色的ARN> \
  --approve \
  --override-existing-serviceaccounts

2. 配置GitLab Runner支持服务账号覆盖 #

• 确保你的EKS托管Runner使用Kubernetes executor，在config.toml中开启服务账号自定义权限：

[[runners]]
  name = "EKS GitLab Runner"
  executor = "kubernetes"
  [runners.kubernetes]
    namespace = "<Runner所在命名空间>"
    service_account_overwrite_allowed = ".*" # 允许作业指定专属服务账号

3. 在项目CI配置中指定团队专属服务账号 #

• 每个团队的项目在.gitlab-ci.yml里，通过kubernetes字段指定自己的服务账号，作业Pod启动后会自动获取对应IAM角色的临时凭证：

deploy_infra:
  stage: deploy
  script:
    - aws cloudformation deploy --stack-name <团队专属栈名> --template-file infra.yml
  tags:
    - eks-runner # 指定使用EKS托管的Runner
  kubernetes:
    service_account: <团队专属服务账号名>

4. 权限隔离验证 #

• 每个团队的IAM角色仅配置自身AWS账号的权限，避免跨账号访问。
• 作业中执行AWS命令无需手动配置密钥，Pod会通过IRSA自动获取临时凭证，权限完全受绑定的IAM角色限制。

内容的提问来源于stack exchange，提问作者Ahmed-F