Kubernetes托管GitHub Actions自托管Runner令牌最佳实践咨询

推荐的令牌方案 #

1. 组织/仓库级注册令牌 #

这是GitHub官方认可的标准方案，完全替代个人PAT，安全性和权限可控性更强：

• 仓库级令牌：在仓库的「Settings」→「Actions」→「Runners」页面生成，仅对当前仓库生效，权限范围最小化。
• 组织级令牌：在组织的「Settings」→「Actions」→「Runners」页面生成，可用于注册组织内所有仓库的Runner，适合规模化部署场景。
• 这类令牌默认有效期90天，到期前可重新生成并更新K8s Secret，无需依赖个人账号的生命周期。

2. GitHub App（规模化场景首选） #

如果需要长期稳定且权限精细化管理的方案，推荐使用GitHub App：

• 创建GitHub App，仅授予管理Runner所需的权限（如administration:read/write），避免过度授权。
• 利用App的私钥生成短期安装访问令牌，或直接通过支持GitHub App集成的部署工具（如官方的runner helm chart）完成Runner注册。
• 优势：与个人账号解耦，权限可按需配置，令牌可通过App生命周期管理，比静态注册令牌更安全。

关键避坑点 #

• 禁用个人PAT：个人PAT绑定用户身份，一旦用户离职或权限变更，所有关联Runner都会失效，且通常带有超出需求的权限范围。
• 放弃GITHUB_TOKEN：工作流内置的GITHUB_TOKEN是临时令牌，仅在工作流运行期间有效，无法用于注册长期运行的自托管Runner。
• 安全存储令牌：将生成的注册令牌或GitHub App私钥存储为Kubernetes Secret，部署时通过环境变量或挂载卷读取，绝对禁止硬编码到配置文件中。

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