自建Gitlab GKE Runner GCS缓存报错403：认证权限不足

问题现象 #

在自建GitLab 15.0实例上配置GCS缓存时，触发如下错误：
ERROR: error while generating GCS pre-signed URL: signing blob: rpc error: code = PermissionDenied desc = Request had insufficient authentication scopes.

环境背景：

• GitLab Runner通过Helm Chart部署在GKE集群
• 当前Helm配置如下：

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:16.04"
        [runners.cache]
          Type = "gcs"
          Path = "runner"
          Shared = true
          [runners.cache.gcs]
            BucketName = "my-bucket-name"

  cache:
      secretName: google-application-credentials

已执行操作：

• 为服务账号配置Storage Legacy Bucket Owner权限
• 将存储桶设置为公共访问
• 检查Runner Pod，发现未挂载google-application-credentials密钥

解决方案 #

1. 修正Helm配置结构 #

核心问题是cache配置的层级错误：GitLab Runner Helm Chart中，cache是顶层配置字段，需与runners同级，而非嵌套在runners下。修正后的配置如下：

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:16.04"
        [runners.cache]
          Type = "gcs"
          Path = "runner"
          Shared = true
          [runners.cache.gcs]
            BucketName = "my-bucket-name"

cache:
  secretName: google-application-credentials

错误的层级会导致Helm Chart无法识别缓存密钥配置，进而不会为Runner Pod挂载对应卷。

2. 确认密钥存在性 #

确保google-application-credentials密钥已在Runner部署的Namespace中创建，密钥需包含service-account-key.json键，值为GCP服务账号的JSON密钥内容。若未创建，可执行以下命令：

kubectl create secret generic google-application-credentials \
  --from-file=service-account-key.json=/path/to/your/service-account-key.json \
  -n <your-runner-namespace>

3. 重新部署Helm Chart #

应用修正后的配置，更新Runner部署：

helm upgrade gitlab-runner gitlab/gitlab-runner \
  -f your-values.yaml \
  -n <your-runner-namespace>

4. 验证挂载状态 #

检查Runner Pod的卷配置，确认密钥已被正确挂载：

kubectl describe pod <runner-pod-name> -n <your-runner-namespace>

在输出的Volumes和Mounts段中，应能看到google-application-credentials相关条目，默认挂载路径为/secrets/gitlab-runner/cache/。

5. 权限与密钥校验 #

若问题仍存在：

• 确认GCP服务账号的JSON密钥文件完整且有效
• 建议使用更精准的roles/storage.objectAdmin权限替代Storage Legacy Bucket Owner，并确保权限已绑定到目标存储桶
• 检查GKE节点的OAuth scopes（若未使用工作负载身份），确保包含https://www.googleapis.com/auth/devstorage.read_write

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