Docker GitHub Actions Runner 环境变量泄漏问题分析与解决方案

问题背景

在使用 myoung34/docker-github-actions-runner 项目时，我们发现了一个潜在的安全隐患：用于配置 Runner 的环境变量会意外泄漏到工作流执行环境中。这种情况可能导致敏感信息暴露或工作流行为异常。

问题本质

Runner 配置环境变量（如 RUNNER_SCOPE、EPHEMERAL 等）原本仅应用于 Runner 初始化阶段，但实际运行时这些变量会被传递到工作流执行环境中。这与 GitHub Actions 官方文档中描述的环境变量行为不符，官方仅定义了特定的默认环境变量集。

技术影响

这种泄漏可能导致以下问题：

1. 安全风险：敏感配置信息可能被工作流脚本意外读取
2. 行为异常：工作流脚本可能错误地依赖这些变量，导致在不同环境表现不一致
3. 调试困难：开发者难以区分预期环境变量和泄漏变量

解决方案分析

目前社区提出了两种解决方案：

临时解决方案

通过自定义启动脚本在 Runner 初始化后但启动前清除这些环境变量：

1. 创建自定义 run.sh 脚本
2. 在脚本中先执行 Runner 配置
3. 通过 pre-start-service.sh 清除配置变量
4. 最后启动 Runner 服务

这种方案虽然有效，但需要用户自行维护额外的脚本文件。

理想解决方案

更完善的解决方案应该是在 Runner 核心逻辑中实现：

1. 在配置阶段完成后自动清除这些变量
2. 仅保留 Runner 运行真正需要的环境变量
3. 确保与 GitHub 官方 Runner 的环境变量行为一致

实施建议

对于项目维护者，建议考虑：

1. 区分配置变量和运行变量
2. 在配置阶段完成后自动清除配置变量
3. 对于必须保留的变量，考虑添加特定前缀（如 CONFIG）以明确其用途
4. 提供明确的文档说明哪些变量会保留到运行环境

总结

环境变量泄漏是一个容易被忽视但影响深远的问题。在使用容器化 Runner 时，开发者应当注意环境变量的生命周期管理，确保配置变量不会意外影响工作流执行。对于 myoung34/docker-github-actions-runner 用户，目前可以采用临时解决方案，同时期待上游实现更完善的变量管理机制。