• 环境
• 保护环境
  • 使用 API 保护环境
• 通过群组成员访问环境
• 部署分支访问
• 对受保护环境的仅限部署访问
• 修改和取消保护环境
• 群组级受保护环境
  • 群组级受保护环境名称
  • 配置群组级成员
  • 保护群组下的关键环境
    • 使用用户界面
    • 使用 API
• 部署审批
• 故障排除
  • 报告者无法运行在下游流水线中部署到受保护环境的触发作业

{{< details >}}

• Tier: Professional, Flagship
• Offering: JihuLab.com, 私有化部署

{{< /details >}}

环境

环境 可以用于测试和生产。

由于部署作业可以由具有不同角色的不同用户发起，因此能够保护特定环境免受未经授权用户的影响非常重要。

默认情况下，受保护的环境确保只有具有适当权限的人才能部署到其中，从而保证环境的安全。

{{< alert type=”note” >}}

极狐GitLab管理员可以使用所有环境，包括受保护的环境。

{{< /alert >}}

要保护、更新或取消保护一个环境，您至少需要拥有维护者角色。

保护环境

先决条件：

• 当授予批准者群组“允许部署”权限时，配置受保护环境的用户必须是要添加的批准者群组的直接成员。否则，该群组或子群组不会在下拉列表中显示。
• 当向批准者群组或项目授予“批准者”权限时，默认情况下，只有批准者群组或项目的直接成员才能获得这些权限。若要将这些权限授予批准者群组或项目的继承成员：
  • 选择启用群组继承复选框。
  • 使用 API。

要保护一个环境：

1. 在左侧边栏中，选择搜索或转到并找到您的项目。
2. 选择 设置 > CI/CD。
3. 展开 受保护的环境。
4. 选择 保护环境。
5. 从环境列表中，选择您要保护的环境。
6. 在允许部署列表中，选择要授予部署访问权限的角色、用户或群组。请记住：
   • 有两个角色可供选择：
     • 维护者：允许项目所有具有维护者角色的用户访问。
     • 开发者：允许项目所有具有维护者和开发者角色的用户访问。
   • 您还可以选择已被邀请到项目的群组。以报告者角色添加到项目中的已邀请群组会出现在仅限部署访问的下拉列表中。
   • 您还可以选择特定用户。用户必须至少拥有开发者角色才能出现在允许部署列表中。

7. 在批准者列表中，选择要授予部署访问权限的角色、用户或群组。请记住：

   • 有两个角色可供选择：
     • 维护者：允许项目所有具有维护者角色的用户访问。
     • 开发者：允许项目所有具有维护者和开发者角色的用户访问。
   • 您只能选择已被邀请到项目的群组。
   • 用户必须至少拥有开发者角色才能出现在批准者列表中。

8. 在审批规则部分：

   • 确保此数字小于或等于规则中的成员数量。
   • 有关此功能的更多信息，请参阅部署审批。
9. 选择 保护。

受保护的环境现在会出现在受保护环境列表中。

使用 API 保护环境

或者，您可以使用 API 来保护环境：

1. 使用一个具有创建环境的 CI 的项目。例如：

   stages:
     - test
     - deploy
   
   test:
     stage: test
     script:
       - 'echo "Testing Application: ${CI_PROJECT_NAME}"'
   
   production:
     stage: deploy
     when: manual
     script:
       - 'echo "Deploying to ${CI_ENVIRONMENT_NAME}"'
     environment:
       name: ${CI_JOB_NAME}
   

2. 使用用户界面创建一个新的群组。例如，此群组名为 protected-access-group，群组 ID 为 9899826。请注意，这些步骤中的其余示例都使用此群组。

   

3. 使用 API 将用户添加到群组作为报告者：

   $ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
          --data "user_id=3222377&access_level=20" "https://jihulab.com/api/v4/groups/9899826/members"
   
   {"id":3222377,"name":"Sean Carroll","username":"sfcarroll","state":"active","avatar_url":"https://jihulab.com/uploads/-/system/user/avatar/3222377/avatar.png","web_url":"https://jihulab.com/sfcarroll","access_level":20,"created_at":"2020-10-26T17:37:50.309Z","expires_at":null}
   

4. 使用 API 将群组作为报告者添加到项目中：

   $ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
          --request POST "https://jihulab.com/api/v4/projects/22034114/share?group_id=9899826&group_access=20"
   
   {"id":1233335,"project_id":22034114,"group_id":9899826,"group_access":20,"expires_at":null}
   

5. 使用 API 将具有受保护环境访问权限的群组添加到项目中：

   curl --header 'Content-Type: application/json' --request POST --data '{"name": "production", "deploy_access_levels": [{"group_id": 9899826}]}' \
        --header "PRIVATE-TOKEN: <your_access_token>" "https://jihulab.com/api/v4/projects/22034114/protected_environments"
   

该群组现在可以访问，并可以在用户界面中查看。

通过群组成员访问环境

用户可以作为群组成员的一部分获得对受保护环境的访问权限。具有报告者角色的用户只能通过这种方法获得对受保护环境的访问权限。

部署分支访问

具有开发者角色的用户可以通过以下任何方法获得对受保护环境的访问权限：

• 作为个人贡献者，通过角色。
• 通过群组成员。

如果用户还拥有对生产环境上部署的分支的推送或合并访问权限，他们具有以下权限：

• 停止环境。
• 删除环境。
• 创建环境终端。

对受保护环境的仅限部署访问

被授予对受保护环境访问权限的用户，但没有对部署到其中的分支的推送或合并访问权限，只能获得部署环境的访问权限。以报告者角色添加到项目中的已邀请群组会出现在仅限部署访问的下拉列表中。

要添加仅限部署访问：

1. 创建一个具有被授予访问受保护环境权限的成员的群组，如果尚不存在。
2. 以报告者角色邀请该群组到项目中。
3. 遵循保护环境中的步骤。

修改和取消保护环境

维护者可以：

• 通过更改允许部署下拉列表中的访问权限，随时更新现有的受保护环境。
• 通过选择该环境的取消保护按钮取消保护受保护的环境。

环境取消保护后，所有访问条目将被删除，如果环境再次受保护，则必须重新输入。

删除审批规则后，以前批准的部署不会显示谁批准了部署。有关批准部署的人员的信息仍然可以在项目审计事件中找到。如果添加了新规则，以前的部署会显示新规则，但没有批准部署的选项。

有关更多信息，请参阅部署安全性。

群组级受保护环境

通常，大型企业组织在开发者和运维之间有明确的权限边界。开发者构建和测试他们的代码，操作员部署和监控应用程序。通过群组级受保护环境，操作员可以限制开发者对关键环境的访问。群组级受保护环境扩展了项目级受保护环境到群组级。

部署的权限可以在下表中说明：

环境	开发者	操作员	类别
开发	允许	允许	低级环境
测试	允许	允许	低级环境
预生产	禁止	允许	高级环境
生产	禁止	允许	高级环境

群组级受保护环境名称

与项目级受保护环境相反，群组级受保护环境使用部署层级作为其名称。

一个群组可能由多个具有唯一名称的项目环境组成。例如，项目 A 有一个 gprd 环境，项目 B 有一个 Production 环境，因此保护特定环境名称的扩展性不佳。通过使用部署层级，两个项目都被识别为 production 部署层级并同时受到保护。

配置群组级成员

{{< history >}}

• 操作员需要拥有拥有者+角色，原为维护者+角色，此角色更改从极狐GitLab 15.3 开始引入，使用名为 group_level_protected_environment_settings_permission 的功能标志。默认启用。
• 功能标志已在极狐GitLab 15.4 中移除。

{{< /history >}}

为了最大化群组级受保护环境的有效性，必须正确配置群组级成员：

• 操作员应被赋予顶级群组的拥有者角色。他们可以在群组级设置页面中维护高级环境（如生产环境）的 CI/CD 配置，其中包括群组级受保护环境、群组级runner和群组级集群。这些配置作为只读条目继承到子项目中。这确保只有操作员可以配置组织范围的部署规则集。
• 开发者不应被赋予顶级群组的开发者角色以上的角色，或被明确赋予子项目的拥有者角色。他们无法访问顶级群组中的 CI/CD 配置，因此操作员可以确保关键配置不会被开发者意外更改。
• 对于子群组和子项目：
  • 关于子群组，如果更高级别的群组已配置了群组级受保护环境，则较低级群组无法覆盖它。
  • 项目级受保护环境可以与群组级设置结合使用。如果同时存在群组级和项目级环境配置，要运行部署作业，用户必须被允许在两个规则集中。
  • 在顶级群组的项目或子群组中，开发者可以安全地被分配为维护者角色，以调整其低级环境（如 testing）。

有了这个配置：

• 如果用户即将在项目中运行部署作业并被允许部署到环境，则部署作业继续。
• 如果用户即将在项目中运行部署作业但不允许部署到环境，则部署作业失败并显示错误消息。

保护群组下的关键环境

要保护群组级环境，请确保您的环境在 .gitlab-ci.yml 中定义了正确的 deployment_tier。

使用用户界面

{{< history >}}

• 在极狐GitLab 15.1 中引入。

{{< /history >}}

1. 在左侧边栏中，选择搜索或转到并找到您的群组。
2. 选择 设置 > CI/CD。
3. 展开 受保护的环境。
4. 从环境列表中，选择您要保护的部署层级。
5. 在允许部署列表中，选择要授予部署访问权限的子群组。
6. 选择 保护。

使用 API

通过使用 REST API 配置群组级受保护环境。

部署审批

受保护环境还可以用于在部署前要求手动审批。有关更多信息，请参阅部署审批。

故障排除

报告者无法运行在下游流水线中部署到受保护环境的触发作业

具有对受保护环境的仅限部署访问权限的用户可能无法运行作业，如果该作业使用了 trigger 关键字。这是因为作业缺少 environment 关键字定义以将作业与受保护环境关联，因此该作业被识别为使用常规 CI/CD 权限模型的标准作业。