在企业中强制实施GitHub Actions策略

可以强制实施策略来管理 GitHub Actions 如何在企业中使用。

谁可以使用此功能？

Enterprise owners

在本文中

什么是 GitHub Actions 的策略？

企业策略控制企业成员使用 GitHub Actions 时可用的选项。

如果不强制实施企业策略，则具有“管理组织操作策略”权限的组织所有者和用户对其组织拥有完全控制权。GitHub Actions

注意

组织中的仓库必须启用 GitHub Actions ，才能运行 CodeQLcode scanning 默认设置和 GitHub Code Quality 工作流。 但是， CodeQL 默认设置 code scanning 不受其他 GitHub Actions 策略的影响（例如限制对公共操作或可重用工作流的访问）。

实施策略

  1. 导航到您的企业。 例如，从 GitHub.com 上的 公司 页面。
  2. 在页面顶部，单击“ 策略”。
  3. 在“ Policies”下，单击“Actions”****。
  4. 配置每个策略后，单击“保存”****。

有关“策略”页面每个部分的更多信息，请继续阅读。

策略

在“策略”部分中，可以控制企业内哪些组织可以使用 GitHub Actions以下选项：

  • 为所有组织启用 GitHub Actions
  • 启用 GitHub Actions 以用于特定组织
  • 对所有组织禁用 GitHub Actions

注意

如果禁用 GitHub Actions或未为一个或多个组织启用该功能，则这会阻止受影响的组织使用 code scanning 和分析 GitHub Code Quality 。

控制对公共操作 和可重用工作流的访问

企业通常希望限制对一组经过良好测试的公共操作 和可重用工作流 的访问，作为供应链治理的一部分。 GitHub 中提供的策略可让您在控制访问的同时，不会阻止 code scanning 和 GitHub Code Quality 使用的动态工作流。

您可以使用以下选项实施严格控制，而无需为 code scanning 和 GitHub Code Quality 定义例外情况或额外配置。

  • 允许所有操作和可重用工作流：可以使用任何操作或可重用工作流，而不管作者是谁或定义它的位置。
  • 允许企业操作 和可重用工作流： 只能使用企业内存储库中定义的操作 和可重用工作流 。 阻止对由 GitHub 编写的所有操作的访问，例如 actions/checkout 操作。
  • 允许企业，并允许选择非企业、操作和可重用工作流____：可以使用企业中存储库中定义的任何操作 或可重用工作流 ，以及与指定条件匹配的任何操作 或可重用工作流 。
  • 要求操作固定到完整长度的提交 SHA：所有操作必须固定到完整长度的提交 SHA 才能使用。 这包括来自贵企业的操作以及由 GitHub 创建的操作。 可重用工作流仍可通过标记引用。 有关详细信息，请参阅“安全使用指南”。

允许企业，并允许选择非企业、操作和可重用工作流____

如果选择此选项，则允许企业中的操作 和可重用工作流 ，并且有以下选项用于允许其他操作 和可重用工作流：

  • 允许由 GitHub 创建的操作： 允许所有由 GitHub 创建、位于 actions 和 github 组织中的操作。
  • 允许来自经验证创作者的 Marketplace 操作： 允许所有由经验证创作者创建且标有 GitHub Marketplace 标签的 操作。
  • 允许 或阻止 指定的操作 和可重用工作流： 允许指定的操作 和可重用工作流 。 可以指定单个操作 和可重用工作流 ，或者整个组织和存储库。

指定操作 和可重用工作流时，请使用以下语法：

  • 若要限制对特定标记的访问或提交操作 或可重用工作流的 SHA，请使用工作流中使用的相同语法来选择操作 或可重用工作流。
    • 对于操作，语法为 OWNER/REPOSITORY@TAG-OR-SHA。 例如，使用 actions/javascript-action@v1.0.1 选择标记或使用 actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f 选择 SHA。
    • 对于可重用的工作流，语法为 OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA. 例如，octo-org/another-repo/.github/workflows/workflow.yml@v1。
  • 要指定模式，请使用通配符 *。
    • 若要允许名称以开头的组织中的所有操作和可重用工作流space-org，请使用space-org*/*。
    • 要允许名称以 octocat 开头的仓库中的所有操作和可重用工作流，请使用 */octocat**@*。
  • 要指定多个模式，请使用 , 分隔各个模式。
    • 若要允许来自 和 组织的所有操作octocat和可重用工作流octokit，请使用 octocat/*, octokit/*。
  • 要阻止特定模式，请使用 ! 前缀。
    • 若要允许组织中的所有操作和可重用工作流space-org，但阻止特定操作，例如space-org/action，使用space-org/*, !space-org/action@*。
    • 默认情况下，仅允许列表中指定的操作 和可重用工作流 。 若要允许所有操作 和可重用工作流 同时阻止特定操作，请使用 *, !space-org/action@*。

策略永远不会限制对运行器文件系统上本地操作的访问（即 uses: 路径以 ./ 开头的情况）。

运行器

默认情况下，任何对存储库拥有管理员访问权限的人都可以为该存储库添加自托管运行器，而自托管运行器存在以下风险：

  • 无法保证自托管运行器托管在临时、干净的虚拟机上。 因此，工作流中不受信任的代码可能会危及它们。
  • 任何能够复刻存储库并发起拉取请求的人都可能危及自托管运行器环境，潜在获取机密和 GITHUB_TOKEN 的访问权限，而其可能对存储库拥有写入权限。

在“运行器”部分，你可以通过禁用存储库级自托管运行器的使用来缓解这些风险。

  • 为所有组织禁用： 禁止在存储库级别创建运行器。
  •           **在所有企业托管用户 (EMU) 存储库中禁用：** 阻止为 托管用户帐户 拥有的存储库创建运行器。

注意

禁止创建存储库级自托管运行器后，工作流仍可访问企业或组织级别的自托管运行器。

禁用标准托管运行器

您可以在企业层面禁用由 GitHub 托管的标准运行器。 此设置要求工作流通过运行器组将运行器指定为目标，并有助于强制执行一致的访问控制和治理策略。

有关 GitHub 托管运行器的作业并发限制信息，请参阅 Actions 限制。

  1. 导航到您的企业。 例如，从 GitHub.com 上的 公司 页面。
  2. 在页面顶部，单击“ 策略”。
  3. 在“ Policies”下，单击“Actions”****。
  4. 滚动到“标准托管运行器”部分，然后单击“对所有组织禁用”。
  5. 单击“ 保存”。

自定义映像

在“自定义映像”部分中，可以控制允许企业中的组织使用以下访问策略创建和管理自定义映像：

  • 为所有组织启用：所有组织（包括将来创建的任何组织）都可以使用或创建自定义映像。
  • 为特定组织启用：只有选定的组织可以使用或创建自定义映像。
  • 对所有组织禁用：任何组织都无法使用或创建自定义映像。

自定义映像保留策略

可以定义自定义映像版本的保留时间以及它们变为非活动状态的时间。

  • 每个映像的最大版本数：限制保留每个映像的版本数。 超过此限制后，将自动删除最早未使用的映像版本。
    • 默认值：20 个版本
    • 可配置的范围：1-100 个版本
  • 未使用的版本保留：删除未使用指定天数的映像版本。 分配给运行器池但未实际使用的映像版本也被视为未使用。
    • 默认值：30 天
    • 可配置范围：1-90 天
  • 最大版本期限：禁用早于指定天数创建的映像版本。 在策略限制提高之前，运行器无法使用禁用的映像版本。
    • 默认值：60 天
    • 可配置的范围：7-90 天

项目和日志保留

默认情况下，工作流生成的项目和日志文件保留 90 天。 可以更改保留期。

  • 对于公共存储库，可配置的保留期为 1 到 90 天。
  • 对于专用和内部存储库，可配置的保留期为 1 到 400 天。

更改仅适用于新的项目和日志文件。

缓存设置

可以配置将在整个企业中应用的最大缓存保留期和大小限制。 如果将“缓存大小逐出限制”增加到计划中包含的 10 GB 以上，则需为缓存条目的任何其他存储付费。

默认情况下：

  • 缓存会在自动删除前保留 7 天。
  • 每个存储库的总缓存存储限制为 10 GB。

可以自定义这些设置，为企业中的缓存保留和缓存存储大小设置最大限制：

  • 缓存保留期：为公共存储库配置最多 90 天，专用存储库和内部存储库最多配置 365 天。
  • 缓存大小逐出限制：每个存储库最多配置 10,000 GB。

在企业级别配置的设置作为最大限制。 组织所有者可以选择为其组织配置限制，但不能超过在企业级别设置的限制。 存储库管理员可以选择为其存储库配置限制，但不能超过组织级别设置的限制。

有关缓存逐出的详细信息，请参阅 依赖项缓存参考。

外部协作者的分支拉取请求工作流

任何人都可以分支公共存储库，然后提交拉取请求以提议更改存储库的工作流。 为防止滥用，某些贡献者创建的拉取请求不会自动运行工作流。

你可以配置哪些拉取请求需要批准后才能运行。

警告

当仅要求首次贡献者（前两个设置）获得批准时，任何有提交或拉取请求合并到存储库的用户都无需批准。 恶意用户可能通过让维护者接受其提交的简单拼写错误或其他无害更改（无论是作为其自己发起的拉取请求的一部分，还是作为其他用户拉取请求的一部分）来满足此要求。

  •           **要求对刚开始使用 GitHub** 的首次参与者进行审批。 从未向存储库提交过代码且拥有新的 GitHub 帐户的用户需要获得批准。
  • 要求首次贡献者获得批准。 要求从未向存储库提交过代码的用户获得批准。
  • 要求所有外部协作者获得批准。 要求所有非组织成员的用户获得批准。

注意

由 pull_request_target 事件触发的基础分支上的工作流将始终运行，无论批准设置如何。

专用存储库中的分支拉取请求工作流

你可以控制用户如何在专用和内部存储库的 pull_request 事件上运行工作流。

  • 运行来自分支拉取请求的工作流。 用户可以运行来自分支拉取请求的工作流。 默认情况下，工作流将使用具有只读权限的 GITHUB_TOKEN，无权访问机密。
  • 向来自拉取请求的工作流发送写入令牌。 工作流将使用具有写入权限的 GITHUB_TOKEN。
  • 向来自拉取请求的工作流发送机密。 所有机密都可供该拉取请求使用。
  • 要求分支拉取请求工作流获得批准。 来自没有写入权限的协作者的拉取请求上的工作流需要获得具有写入权限的人员的批准才能运行。

如果为企业启用了某个策略，可以在单个组织或存储库中选择性禁用该策略。 如果为企业禁用了某个策略，则单个组织或存储库无法启用该策略。

工作流权限

在“工作流权限”部分中，可以设置授予 **** 的GITHUB_TOKEN权限。

  • 读取和写入权限：GITHUB_TOKEN 的默认权限取决于企业或组织的创建时间：

    • 2023 年 2 月 2 日或之后创建 – 所有范围默认为只读访问权限。
    • 2023 年 2 月 2 日之前创建 – 所有范围默认为读写访问权限。

  • 读取存储库内容和包权限： 默认情况下，GITHUB_TOKEN仅对 contents 和 packages 范围拥有读取权限。 更宽松的设置不能选为单个组织或存储库的默认设置。

任何对存储库拥有写入权限的人仍然可以通过编辑工作流文件中的 GITHUB_TOKEN 键，修改授予 permissions 的特定工作流权限。

默认情况下，已禁用允许 GitHub Actions 创建和批准拉取请求。 如果启用此设置，GITHUB_TOKEN 可以创建和批准拉取请求。