GitLab Runner跨集群部署至AKS权限问题咨询

我有一个GitLab流水线任务需要部署到某AKS集群，流水线运行在通过Helm部署于另一Kubernetes集群的GitLab Runner上。GitLab Agent已通过Helm Chart成功部署在目标集群，Runner也已成功部署在自身集群，但Runner因权限问题无法部署至目标集群——我已创建ServiceAccount，但部署始终使用命名空间创建时生成的默认ServiceAccount。

流水线报错信息：

helm upgrade "test-${ENVIRONMENT}" ./helloworld-chart --install -n $NAMESPACE -f "./helloworld-chart/values.yaml"
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /builds/test-deploy-agent-ci.tmp/KUBECONFIG
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /builds/test-deploy-agent-ci.tmp/KUBECONFIG
Error: query: failed to query with labels: secrets is forbidden: User "system:serviceaccount:test-runner:default" cannot list resource "secrets" in API group "" in the namespace "default"

核心疑问：如何让部署在另一集群的GitLab Runner获得权限，部署至运行有GitLab Agent的目标集群？

补充：我已创建ServiceAccount、生成Secret及config.toml文件，据资料需将该配置文件传给Helm部署的Runner，但不知操作方法，恳请指导。

一、绑定自定义ServiceAccount到GitLab Runner Pod #

你需要让Runner Pod使用你创建的自定义ServiceAccount，而不是默认的default账号：

1. 修改Helm部署Runner的values.yaml文件，添加以下配置：

runner:
  serviceAccountName: 你的自定义ServiceAccount名称

2. 重新部署Runner（如果是首次部署直接用该values文件，已部署则执行升级）：

helm upgrade --install gitlab-runner gitlab/gitlab-runner \
  --namespace test-runner \
  -f /path/to/your/values.yaml

或者直接通过命令行参数指定：

helm upgrade --install gitlab-runner gitlab/gitlab-runner \
  --namespace test-runner \
  --set runner.serviceAccountName=你的自定义ServiceAccount名称

二、将目标AKS集群的KubeConfig注入Runner Pod #

因为Runner所在集群和目标AKS集群相互独立，需要把目标集群的授权配置挂载到Runner Pod中：

1. 在Runner所在集群的test-runner命名空间下，创建存储目标集群KubeConfig的Secret：

kubectl create secret generic target-aks-kubeconfig \
  --namespace test-runner \
  --from-file=kubeconfig=/path/to/your/target-aks-kubeconfig-file

2. 修改Runner的Helm配置，挂载这个Secret到Pod内部，并指定环境变量指向该配置文件：

runner:
  # 绑定自定义ServiceAccount
  serviceAccountName: 你的自定义ServiceAccount名称
  # 设置KUBECONFIG环境变量
  envVars:
    - name: KUBECONFIG
      value: /etc/kubeconfig/target-aks-config
  # 挂载Secret到Pod路径
  volumeMounts:
    - name: target-kubeconfig
      mountPath: /etc/kubeconfig
      readOnly: true
  volumes:
    - name: target-kubeconfig
      secret:
        secretName: target-aks-kubeconfig
        items:
          - key: kubeconfig
            path: target-aks-config

同样可以通过命令行参数直接部署/升级：

helm upgrade --install gitlab-runner gitlab/gitlab-runner \
  --namespace test-runner \
  --set runner.serviceAccountName=你的自定义ServiceAccount名称 \
  --set runner.envVars[0].name=KUBECONFIG \
  --set runner.envVars[0].value=/etc/kubeconfig/target-aks-config \
  --set runner.volumeMounts[0].name=target-kubeconfig \
  --set runner.volumeMounts[0].mountPath=/etc/kubeconfig \
  --set runner.volumeMounts[0].readOnly=true \
  --set runner.volumes[0].name=target-kubeconfig \
  --set runner.volumes[0].secret.secretName=target-aks-kubeconfig \
  --set runner.volumes[0].secret.items[0].key=kubeconfig \
  --set runner.volumes[0].secret.items[0].path=target-aks-config

三、验证配置有效性 #

1. 重新部署Runner后，进入Pod检查KubeConfig是否正确挂载：

kubectl exec -it <你的runner-pod名称> -n test-runner -- cat /etc/kubeconfig/target-aks-config

2. 在流水线中添加测试步骤，验证是否能访问目标集群：

kubectl get nodes

如果能正常返回目标集群的节点列表，说明权限配置生效。

额外注意事项 #

• 确保你在目标AKS集群创建的ServiceAccount已绑定足够权限（比如通过ClusterRole和ClusterRoleBinding授予部署资源、读取Secret等权限）。
• 流水线中出现的KubeConfig权限警告，可在流水线步骤中添加chmod 600 $KUBECONFIG命令修正，不影响功能的话也可直接忽略。

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