通过Helm在Kubernetes部署GitLab Runner时遇权限拒绝问题

1. 检查Pod的HOME环境变量配置 #

GitLab Runner默认会在$HOME/.gitlab-runner目录下存储系统ID文件，若HOME环境变量被错误设置为/，就会触发权限报错。

• 执行命令查看Pod的环境变量：

  kubectl exec -it <你的runner-pod名称> -- env | grep HOME
  

• 若输出为HOME=/，在Helm的values.yaml中添加环境变量修正：

  env:
    - name: HOME
      value: /home/gitlab-runner
  

2. 验证SecurityContext配置 #

确保Runner Pod以gitlab-runner用户（UID/GID 1000）运行，避免因权限不足无法访问目标目录：

• 在values.yaml中确认以下配置：

  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000
  

• 若集群有Pod Security Policy（PSP）或强制安全上下文约束，需确保这些配置未被覆盖。

3. 检查本地迁移镜像的用户与工作目录配置 #

镜像迁移过程中可能丢失原镜像的USER/WORKDIR配置，导致Runner运行时使用错误的用户或路径：

• 查看本地镜像的配置：

  docker inspect <你的本地runner镜像> | grep -A 5 "User"
  docker inspect <你的本地runner镜像> | grep "WorkingDir"
  

• 正常输出应显示User: "gitlab-runner"和WorkingDir: "/home/gitlab-runner"，若缺失需重新迁移镜像（直接拉取原镜像后推送到本地仓库，避免自定义构建时修改配置）。

4. 排查持久化卷的权限问题 #

若启用了持久化存储，需确保挂载到/home/gitlab-runner的卷权限正确：

• 确认values.yaml中持久化配置的fsGroup已设置为1000，确保gitlab-runner用户拥有卷的读写权限：

  persistence:
    enabled: true
    fsGroup: 1000
    accessMode: ReadWriteOnce
    size: 1Gi
  

• 若使用emptyDir，无需额外配置，但需确保Pod的securityContext已正确设置。

5. 检查自定义config.toml的路径配置 #

若你在values.yaml中自定义了config.toml模板，需确认未强制指定system_id_file路径到根目录：

• 检查config.template.toml相关配置，确保未出现类似：

  system_id_file = "/.gitlab-runner/system_id"
  

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