GitLab Runner中使用ServiceAccount Token执行kubectl时提示未授权

我来帮你梳理几个我实际碰到过的类似场景的排查方向，应该能帮你定位到根因：

1. 先确认Runner Pod实际使用的ServiceAccount权限 #

虽然你本地验证了ServiceAccount Token，但要注意GitLab Runner的Kubernetes执行器默认会用自身Pod绑定的ServiceAccount——除非你在Runner配置里特意指定了serviceAccountName，否则你配置的KUBECONFIG可能根本没生效：

• 先找到Runner Pod所在的命名空间：

  kubectl get pods -n <你的Runner部署命名空间>
  

• 查看该Pod绑定的ServiceAccount：

  kubectl describe pod <RunnerPod名称> -n <你的Runner部署命名空间> | grep ServiceAccount
  

• 验证这个ServiceAccount是否有操作目标资源的权限，比如要部署应用的话：

  kubectl auth can-i create deployments -n <目标应用命名空间> --as=system:serviceaccount:<Runner部署命名空间>:<查到的SA名称>
  

  如果返回no，那就是权限不足，需要给这个SA绑定对应的Role/ClusterRole。

2. 直接在Runner Pod内验证KUBECONFIG的有效性 #

你说本地验证了上下文，但Pod内的环境可能有差异，直接进去排查最准确：

• 进入Runner Pod的终端：

  kubectl exec -it <RunnerPod名称> -n <你的Runner部署命名空间> -- bash
  

• 先确认KUBECONFIG环境变量和配置文件路径：

  echo $KUBECONFIG
  cat $KUBECONFIG
  

• 尝试执行一个简单的集群操作，看具体报错（比如权限拒绝？还是API Server连不上？）：

  kubectl get namespaces
  

• 还要注意配置文件里的证书/Token路径是否在Pod内存在，以及文件权限是否可读：

  ls -l $(dirname $KUBECONFIG)
  

3. 排查集群内部的网络连通性 #

有时候本地能访问API Server，但Runner Pod所在的网络可能不通：

• 先拿到API Server的地址：

  kubectl get endpoints kubernetes -n default
  

• 在Runner Pod内ping这个地址，看是否能连通：

  ping <API Server的IP地址>
  

• 如果用域名访问API Server，检查Pod内的DNS解析是否正常：

  nslookup kubernetes.default.svc.cluster.local
  

• 也可以用curl直接测试API接口：

  curl -k https://<API Server的IP地址>:6443/api/v1/namespaces
  

  （如果是自签证书，记得加-k跳过验证）

4. 检查GitLab Runner配置是否有参数冲突 #

GitLab Runner的Kubernetes执行器配置（config.toml里的[[runners.kubernetes]]段）有一些参数会优先于KUBECONFIG，比如：

• 如果配置了host、bearer_token、namespace这些参数，Runner会直接用这些设置，忽略你指定的KUBECONFIG
• 核对你的Runner配置，看看是否有这类覆盖性的参数，导致KUBECONFIG没生效

5. 验证Pod内ServiceAccount Token的有效性 #

即使本地的Token没问题，Pod内挂载的Token可能有有效期或者绑定问题：

• 在Runner Pod内查看当前使用的Token：

  cat /var/run/secrets/kubernetes.io/serviceaccount/token
  

• 用这个Token直接调用API Server，验证权限：

  curl -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" -k https://<API Server的IP地址>:6443/api/v1/namespaces/<目标应用命名空间>
  

• 同时检查这个ServiceAccount是否绑定了正确的角色：

  kubectl get rolebindings,clusterrolebindings | grep <查到的SA名称>
  

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