self-hosted runner 默认不安全，因其绕过 GitHub 托管 runner 的沙箱、网络隔离与自动清理机制，易被恶意 fork PR 触发任意命令并危害宿主机。
self-hosted runner 为什么默认不安全
GitHub Actions 的 self-hosted runner 运行在你自己的机器上，但它的执行权限和网络环境完全由你控制——这意味着它天然绕过 GitHub 托管 runner 的沙箱、网络隔离和自动清理机制。一旦 workflow 中的
步骤被恶意 PR 触发（比如通过 fork 提交的 PR），
就可能执行任意命令，读取宿主机凭证、访问内网服务、甚至反向连接攻击者服务器。
如何防止 fork PR 自动触发敏感 job
这是最常见也最容易被忽略的风险点。默认情况下，fork 发起的 PR 也能触发你的 workflow，且其
不会注入（这点没错），但
脚本本身仍会在你的私有 runner 上执行。
在 workflow 文件中显式添加
条件判断
更稳妥的做法是：对所有敏感 job（比如部署、发布、访问内部 API）加
限制，并配合
和
隔离
禁用 fork PR 的自动运行：在仓库 Settings → Actions → General → “Workflow permissions” 中关闭 “Allow GitHub Actions to create and approve pull requests”，并勾选 “Restrict workflows to selected actions”
runner 进程该用什么用户身份运行
绝不能用
或当前登录用户直接启动
。runner 进程若以高权限运行，一个
或
就能毁掉整台机器。
创建专用低权限系统用户，例如
，无 shell、无 sudo 权限、home 目录仅限 runner 工作区
用
管理时，在 service 文件中明确指定
和
工作目录（
）和 runner 根目录必须属主为该用户，且禁止其他用户写入：
，
runner 和 workflow 之间怎么隔离敏感信息
是加密传给 runner 的，但一旦解密进环境变量，就可能被
、进程内存 dump 或日志泄露。尤其当多个 workflow 共用一个 runner 时，缓存、临时文件、环境变量残留都可能交叉污染。
GitHub Copilot
GitHub AI编程工具，实时编程建议
下载
立即学习
“
Python免费学习笔记（深入）
”；
避免在
下直接暴露
；改用
或短生命周期的子 shell 传参
禁用 runner 的
跳过逻辑：确保每次 job 后
目录被彻底清空（检查
日志是否含
）
不要复用 runner 实例跑 CI 和 CD：部署类 job 必须独占 runner，或使用标签（
）物理隔离
真正难的不是配置几行 YAML，而是持续保证 runner 所在机器的最小权限状态、网络出向白名单、以及对 workflow 拉取内容的零信任——哪怕只改了一行
，也要当成新代码审查。
runrunnersecretsrunif: github.event_name == 'pull_request' && github.repository_owner == 'your-org' || github.event_name != 'pull_request'permissions:concurrencyenvrootrun.shrm -rf /curl | bashgh-runnersystemdUser=gh-runnerGroup=gh-runner_workchmod 755 /opt/my-runnerchmod 700 /opt/my-runner/_worksecretsps auxenv:${{ secrets.MY_TOKEN }}steps[*].with.argscleanup_workcleanupRemoving work directoryruns-on: [self-hosted, deploy]run