Actions Runner Controller 认证失败问题分析与解决方案

问题背景

在使用Actions Runner Controller (ARC)管理自托管运行器时，用户遇到了401 "Bad credentials"错误。具体表现为监听器Pod无法获取运行器注册令牌，导致无法创建运行器Pod。该问题发生在尝试为pytorch/xla仓库配置运行器时，而使用相同配置为其他仓库却能正常工作。

错误现象

监听器Pod日志显示以下关键错误信息：

failed to get runner registration token on refresh: unexpected response from Actions service during registration token call: 401 - {"message":"Bad credentials","documentation_url":"https://docs.github.com/rest"}

问题排查过程

1. 认证方式确认：用户最初怀疑是GitHub应用认证配置问题，确认使用的是GitHub App而非个人访问令牌(PAT)进行认证。

2. 组织权限验证：用户测试了在不同组织间的配置，发现：

   • 在个人仓库和新建测试组织中配置成功
   • 在目标组织(pytorch)中配置失败

3. 配置检查：确认了GitHub App已正确安装到目标组织，并拥有所有必要的权限：

   • 仓库内容：读写权限
   • 元数据：只读权限
   • 组织成员：只读权限
   • 部署：读写权限
   • 拉取请求：读写权限
   • 工作流：读写权限

4. 网络限制排查：确认目标组织没有设置IP白名单限制，也没有禁用自托管运行器。

根本原因

最终发现问题的根本原因是Kubernetes Secret缓存机制。当用户更新认证密钥后，ARC监听器相关的Secret没有自动更新，导致继续使用旧的无效凭证。

解决方案

1. 清理旧Secret：删除arc-systems命名空间下的所有相关Secret

   kubectl delete secret -n arc-systems --all
   

2. 重启相关Pod：删除监听器和控制器Pod，使其自动重建

   kubectl delete pod -n arc-systems -l app=gha-runner-scale-set-controller
   kubectl delete pod -n arc-runners -l app=gha-runner-scale-set-listener
   

3. 验证新配置：系统会自动重建Secret和Pod，此时应使用新的认证信息成功获取运行器注册令牌。

经验总结

1. Secret管理：在Kubernetes中更新Secret后，依赖这些Secret的组件可能不会自动感知变化，需要手动触发重建。

2. 认证方式选择：虽然GitHub App认证比PAT更安全，但配置过程更复杂，需要特别注意权限设置和安装范围。

3. 多组织场景：GitHub App可以跨组织使用，但必须确保：

   • App已正确安装到目标组织
   • 安装时授予了足够权限
   • 没有组织级别的访问限制

4. 调试技巧：当遇到认证问题时，可以尝试：

   • 在更简单的环境(如个人仓库)复现问题
   • 检查所有相关组件的日志
   • 确认Secret内容是否与预期一致

最佳实践建议

1. 变更管理：修改认证信息后，应主动重启相关组件以确保使用最新配置。

2. 监控配置：建立对监听器状态的监控，及时发现认证失败情况。

3. 文档记录：详细记录GitHub App的配置参数和安装情况，便于问题排查。

4. 测试验证：在应用到生产环境前，先在测试环境验证配置有效性。

通过以上分析和解决方案，用户成功解决了ARC认证失败的问题，为类似场景提供了有价值的参考经验。