GitHub Actions Runner Controller部署K8s自托管Runner遇权限问题

使用GitHub Actions Runner Controller在Kubernetes集群中部署自托管Runner后，作业执行失败，报错：

Error: Error: Missing file at path: /runner/_work/_temp/_runner_hook_responses/2ee89e97-2fec-446b-bf18-06e0843fb51a.json

在Runner Pod中添加休眠操作后，进入Pod查看发现权限异常：

runner@arc-demo-rd-zzv72-l7rc4:/runner$ ls -aln
total 104
drwxrwsrwx. 9 1000 1001  4096 Jun 14 23:59 .
drwxr-xr-x. 1    0    0  4096 Jun 14 23:59 ..
-rw-r--r--. 1 1000 1001   263 Jun 14 23:59 .credentials
-rw-------. 1 1000 1001  1667 Jun 14 23:59 .credentials_rsaparams
-rw-r--r--. 1 1000 1001     0 Jun 14 23:59 .env
-rw-r--r--. 1 1000 1001    86 Jun 14 23:59 .path
-rw-r--r--. 1 1000 1001   391 Jun 14 23:59 .runner
drwxr-sr-x. 4 1000 1001  4096 Jun 14 23:59 _diag
drwxrwsr-x. 7 1000 1000  4096 Jun 14 23:59 _work
drwxrwsr-x. 2 1000 1000  4096 Jun 14 23:59 _work1
drwxr-sr-x. 4 1000 1001 16384 Jun 14 23:59 bin
-rwxr-xr-x. 1 1000 1001  2458 Jun 14 23:59 config.sh
-rwxr-xr-x. 1 1000 1001   646 Jun 14 23:59 env.sh
drwxr-sr-x. 6 1000 1001  4096 Jun 14 23:59 externals
drwxr-sr-x. 2 1000 1001  4096 Jun 14 23:59 externalstmp
drwxr-sr-x. 2 1000 1001  4096 Jun 14 23:59 k8s
-rw-r--r--. 1 1000 1001  1487 Jun 14 23:59 run-helper.cmd.template
-rwxr-xr-x. 1 1000 1001  2522 Jun 14 23:59 run-helper.sh
-rwxr-xr-x. 1 1000 1001  2522 Jun 14 23:59 run-helper.sh.template
-rwxr-xr-x. 1 1000 1001  2537 Jun 14 23:59 run.sh
-rwxr-xr-x. 1 1000 1001    65 Jun 14 23:59 safe_sleep.sh
-rwxr-xr-x. 1 1000 1001  5232 Jun 14 23:59 svc.sh
runner@arc-demo-rd-zzv72-l7rc4:/runner$ cd _work1
runner@arc-demo-rd-zzv72-l7rc4:/runner/_work1$ cd ..
runner@arc-demo-rd-zzv72-l7rc4:/runner$ cd _work
bash: cd: _work: Permission denied

_work是作业工作目录，Runner进程无法对其操作，手动创建的_work1则一切正常。请问两者存在差异的原因是什么？

核心差异来自目录创建方式与Kubernetes安全配置的交互，具体如下：

1. 创建主体与权限继承逻辑不同

   • _work是Kubernetes卷挂载机制自动创建的（通常是emptyDir或PVC），其属主、属组、权限由卷的默认配置或Pod的securityContext（如fsGroup参数）决定。从输出可见，_work的属组为1000，但runner用户的主组是1001，两者不匹配，导致权限校验失败。
   • _work1是runner用户手动创建的，其权限会继承父目录/runner的g+s（强制组继承）属性，且由于是在Pod内部创建，属组与用户操作时的有效组完全匹配，因此权限兼容无问题。

2. SELinux或挂载限制导致的访问拦截
   你提到即使sudo也无法操作_work，说明问题超出普通Unix权限范畴：

   • 挂载的卷可能带有不匹配的SELinux上下文标签，Pod进程（包括root）被SELinux策略拦截，无法访问目录。
   • 卷可能被错误配置为只读挂载，或添加了noexec等限制选项，导致无法进入目录或执行操作。

3. Kubernetes安全上下文配置冲突
   如果Pod的securityContext中设置了fsGroup: 1000但runAsGroup: 1001，挂载卷时Kubernetes会将卷的属组设为1000并开启g+s位，但runner用户的主组是1001，进程有效组也是1001，此时即使目录的用户权限是rwx，也会因SELinux或文件系统的额外限制被拦截；而手动创建的目录因继承Pod内部的SELinux上下文，可正常访问。

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