如何在公开GitHub仓库中安全使用自托管Runner执行Actions工作流

核心安全保障措施 #

要在公开仓库中安全使用自托管Runner，需严格执行以下规则，这是规避核心风险的基础：

• 仅信任已审批协作者：开启仓库GitHub Actions设置中的「Require approval for all outside collaborators」选项，确保所有外部贡献者的操作都需要审批，且内部协作者均为可信人员。
• 彻底禁用PR相关触发器：绝对不配置pull_request、pull_request_target等与PR相关的工作流触发器，仅保留仓库所有者/协作者可控的触发事件（如push到受保护分支、release发布事件等），从根源上避免fork仓库的恶意PR触发自托管Runner。
• 最小权限原则配置Runner：以非管理员权限运行自托管Runner，限制Runner对本地硬件、文件系统的访问权限，仅开放必要资源给工作流进程，降低恶意代码的破坏范围。

需警惕的潜在风险 #

除核心隐患外，还有容易被忽略的风险点：

• 触发器误配置：若工作流未明确指定触发事件，可能继承默认包含的PR触发器，因此所有工作流必须显式声明on字段，仅列出安全的触发事件。
• 第三方Action漏洞：工作流中使用的第三方Action可能存在恶意代码，即使是可信协作者提交的修改，也要严格审核每个Action的来源和版本，优先使用官方或知名开源项目的Action。
• 敏感信息泄露：自托管Runner环境中绝对不能存储明文敏感信息（如API密钥、硬件配置凭证），所有敏感数据需通过GitHub Secrets管理，且仅在必要的工作流步骤中调用。

替代方案对比 #

若对上述安全配置的长期维护存在顾虑，可考虑以下替代方案，但各有局限：

• 隔离型自托管Runner服务：使用提供临时隔离环境的Runner服务（如actuated），每个工作流在独立的干净虚拟机中执行，避免污染主机环境，但目前普及度较低。
• 外部CI系统：自建Jenkins等独立CI系统，完全自主控制流水线触发逻辑和运行环境，但需要重新编写流水线配置，前期搭建和长期维护成本较高。
• 双仓库分离方案：将产品代码放在公开仓库，自托管Runner的工作流代码放在私有仓库，通过触发私有仓库的工作流执行硬件测试，但工作流与产品代码分离，会降低开发体验。

总结 #

如果能严格执行核心安全配置，并持续监控工作流变更和Runner状态，公开仓库中使用自托管Runner是可行的，但需要长期保持对配置的警惕，避免误操作引入风险。

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