Actions Runner Controller 中 workflow_call 触发时 Pod 安全上下文缺失问题分析

问题背景

在 Kubernetes 环境中使用 Actions Runner Controller (ARC) 部署 GitHub Actions 自托管运行器时，用户发现当工作流通过 workflow_call 触发时，会产生权限问题。具体表现为工作流任务无法写入临时文件，出现 EACCES 权限拒绝错误。

现象描述

当工作流通过 workflow_call 方式触发时，系统会创建两个关联的 Pod：

1. 主运行器 Pod（如 runner-name-wp8ht-runner-b22sr）
2. 工作流 Pod（如 runner-name-wp8ht-runner-b22sr-workflow）

用户通过 Helm chart 配置了主运行器 Pod 的安全上下文，特别是设置了 fsGroup 为 123（对应容器内 docker 组的 GID）。然而，工作流 Pod 却没有继承这个安全上下文配置，导致文件系统权限问题。

技术原理分析

在 Kubernetes 环境中，Pod 的安全上下文（securityContext）对于容器内进程的文件系统权限至关重要。fsGroup 设置特别重要，因为它决定了容器内进程创建文件时的组所有权。

Actions Runner Controller 的工作机制是：

1. 主运行器 Pod 负责与 GitHub 通信并接收工作流任务
2. 当工作流被触发（包括 workflow_call 方式），控制器会动态创建工作流 Pod 来执行具体任务

问题根源在于这两个 Pod 的配置是独立处理的。通过 Helm chart 配置的 template.spec.securityContext 只会应用于主运行器 Pod，而不会自动传播到工作流 Pod。

解决方案

根据项目维护者的建议，正确的解决方法是使用 hook extensions 机制来配置工作流 Pod 的安全上下文。hook extensions 是 Actions Runner Controller 提供的一个扩展点，允许用户在创建工作流 Pod 时注入自定义配置。

具体实现步骤应包括：

1. 创建并配置 hook extension
2. 在 extension 中明确设置工作流 Pod 的安全上下文
3. 确保 fsGroup 与主运行器 Pod 保持一致（如示例中的 123）

最佳实践建议

1. 一致性配置：确保主运行器 Pod 和工作流 Pod 的安全上下文配置一致，特别是 fsGroup 值
2. 权限规划：提前规划好容器内用户和组的权限设置，避免临时调整
3. 测试验证：在部署到生产环境前，充分测试各种触发方式下的权限行为
4. 文档参考：详细阅读项目文档中关于 hook extensions 的说明，了解所有可配置项

总结

在 Kubernetes 环境中使用 Actions Runner Controller 时，理解不同 Pod 的配置继承关系非常重要。特别是对于通过 workflow_call 等间接方式触发的工作流，必须通过正确的扩展机制（如 hook extensions）来确保所有相关 Pod 都能获得必要的安全配置。这个问题提醒我们，在复杂的自动化系统中，权限管理需要全面考虑所有可能的执行路径和运行时环境。