GitLab流水线引入Environment后出现403请求失败问题求助

DevOps 小满

2026-7-20

排查思路与解决方案

核心原因推测

GitLab Environments会自动注入K8s认证相关的环境变量或配置，导致kubectl优先使用了GitLab提供的Bearer Token，而非你原本配置的kubeconfig——这就是为什么你看到多了一个Authorization请求头，且这个Token没有操作abcd-service-hc服务的权限。

具体排查&解决步骤

强制指定kubeconfig路径：直接在kubectl命令里显式指定你的配置文件路径，绕过GitLab的自动注入：
```
kubectl apply -f 你的清单目录/ --kubeconfig=/绝对路径/到/你的/kubeconfig
```
检查CI环境变量：在部署步骤前加一行命令，确认GitLab有没有偷偷设置KUBECONFIG或KUBE_TOKEN：
```
env | grep -E "(KUBECONFIG|KUBE_TOKEN)"
```
如果有，要么unset掉，要么在CI变量里手动覆盖KUBECONFIG为你的配置路径。
验证GitLab注入的Token权限：把kubectl verbose输出里的Bearer Token拿出来，用curl直接测K8s API：
```
curl -H "Authorization: Bearer 你拿到的Token" https://你的K8sAPI地址/api/v1/namespaces/你的命名空间/services/abcd-service-hc
```
要是返回403，说明这个Token确实没权限，得去GitLab里调整集群关联的服务账号权限，给它加services的create/update权限。
禁用GitLab自动K8s集成：如果不需要GitLab Environments的K8s自动管理功能，直接在CI脚本开头unset掉相关变量：
```
unset KUBECONFIG
kubectl apply -f 你的清单目录/
```
检查原有kubeconfig的认证优先级：确认你的kubeconfig里的用户认证没有被token覆盖，比如看一下配置：
```
cat /路径/到/你的/kubeconfig | grep -A5 -B5 "user"
```
要是里面有token字段，可能和GitLab的注入冲突，暂时注释掉试试。