如何防止 GitHub Actions 工作流程被 fork 仓库事件触发?

9
最近我发现,如果你的代码仓库是公开的,那么任何人都可以触发 GitHub Actions 中的 on pull_request 事件。
具体来说:
  1. 有人克隆我的代码库
  2. 他们在 .github/workflows 中添加一个在 pull_request 事件上运行的 something.yml 文件
  3. 他们创建一个拉取请求
然后这个拉取请求中指定的操作就会被运行。如果你有自托管的运行器,那么全球任何人都可以以自托管运行器用户的身份在你的服务器上运行 shell 命令。
如果按照我的设想那样工作,那么任何人都可以通过提交拉取请求在你的服务器上运行任意代码。我尝试了一下,似乎是这种情况。
那么如何才能让GitHub Actions只接受白名单中的钩子来触发操作呢?或者说,如何才能安全地使用公共代码库和自托管的运行器?我看到了警告,只是假设不接受来自未知来源的拉取请求就可以了。

pull_request_target - riQQ
pull_request_target 不起作用。我没有办法强制要求具有新工作流程的拉取请求指定 pull_request_target 而不是 pull_request。 - Zach Smith
你说得对,我搞混了。 - riQQ
3个回答

3
添加了一个配置选项来帮助保护自托管的 Runner。如果您拥有一个公共仓库和一个自托管的 Runner,则应始终启用下面 Actions 配置屏幕中所示的 "要求所有外部协作者的批准" 选项。
新默认设置为要求所有首次贡献者运行工作流程时需要批准。
然而,GitHub 仍建议不要在公共存储库中使用自托管的 Runner。他们明确指出GitHub 上的公共存储库几乎永远不应该使用自托管的 Runner。 此页面还提到要使用CodeOwners监视存储工作流程文件的目录(.github/workflows)的更改。 GitHub Action Configuration

1
据我所知,你不能这样做。 这就是跑步者和GitHub Actions的设计工作方式。 如果您有一个公共存储库,则拥有自托管的运行器真的不是一个好主意。 即使在§Self-hosted runner security with public repositories部分的文档中也提到:

我们建议您不要在公共存储库中使用自托管的运行程序。

您的公共存储库的分支可能会通过创建执行工作流中的代码的拉取请求,在自托管的运行程序机器上运行危险代码。

这不是GitHub托管的运行程序的问题,因为每个GitHub托管的运行程序始终是一个干净的隔离虚拟机,并且在作业执行结束时被销毁。

考虑到这一点,您有两个选择:

  1. 除非您真的需要它,否则不要使用自托管的运行程序。 如果需要,请将您的repo设置为私有。

  2. 切换到GitHub托管的运行程序。


2
使用自托管的 Runner 的一个很好的理由是,组织的网络不允许在该网络内部的服务器上进行 SSH 连接。GitHub Actions 默认情况下如此不安全,这令人难以置信。 - Zach Smith
2
特别是考虑到这很容易防止 - 即允许禁用事件触发器。 - Zach Smith

1
据我所知:
  • 在公共仓库(免费版)上无法禁用此功能
  • 默认情况下,在私有仓库中无法在拉取请求上运行操作
  • 如果您使用的是GitHub企业版,则可以启用来自分支的工作流程

如果您当前的工作流程没有 on: pull_request 触发器,那么任何 PR 都不会触发 CI 运行。 - Roman Dodin
你可以通过该触发器添加一个工作流程作为拉取请求。(我认为那就是问题所在) - Zach Smith
但如果恶意贡献者添加了一个带有 pull_request 触发器的工作流,它将不会被执行(动作不会运行,因为没有现有的触发器会在该动作上触发)。这是我的理解。 - Roman Dodin
我认为那是合乎逻辑的。但在撰写这个问题时,情况并非如此。那正是安全问题所在。我花了一些时间才真正相信它,但我记得测试过它,确实发生了。 - Zach Smith
换句话说,不要在公共 Git 存储库上拥有自托管的 Runner。 - Zach Smith

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接