受保护的环境

环境 可用于测试和生产目的。

由于部署任务可能由不同角色的用户发起，能够保护特定环境免受未授权用户的影响非常重要。

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

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

保护环境

先决条件：

• 在向审批者组授予 允许部署 权限时，配置受保护环境的用户必须是待添加审批者组的 直接成员。否则，该组或子组不会出现在下拉列表中。更多信息请参见 问题 #345140。
• 在向审批者组或项目授予 审批者 权限时，默认情况下只有审批者组或项目的直接成员会收到这些权限。要将这些权限也授予审批者组或项目的继承成员：
  • 选中 启用组继承 复选框。
  • 使用 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://gitlab.com/api/v4/groups/9899826/members"
   
   {"id":3222377,"name":"Sean Carroll","username":"sfcarroll","state":"active","avatar_url":"https://gitlab.com/uploads/-/system/user/avatar/3222377/avatar.png","web_url":"https://gitlab.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://gitlab.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://gitlab.com/api/v4/projects/22034114/protected_environments"

该组现在拥有访问权限，可以在界面中看到。

通过组成员身份访问环境

用户可能作为 组成员身份 的一部分被授予对受保护环境的访问权限。具有报告者角色的用户只能通过此方法被授予对受保护环境的访问权限。

部署分支访问

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

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

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

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

仅部署访问受保护环境

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

要添加仅部署访问：

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

修改和取消保护环境

维护者可以：

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

环境取消保护后，所有访问条目都会被删除，如果环境重新被保护，必须重新输入。

审批规则删除后，之前已批准的部署不会显示谁批准了该部署。关于谁批准了部署的信息仍然在 项目审计事件 中可用。如果添加了新规则，之前的部署会显示新规则，但没有批准部署的选项。问题 506687 建议即使审批规则被删除，也显示部署的完整审批历史。

更多信息，请参见 部署安全性。

组级受保护环境

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

部署权限可以用下表说明：

环境	开发者	运维人员	类别
开发环境	允许	允许	低环境
测试环境	允许	允许	低环境
预发布环境	不允许	允许	高环境
生产环境	不允许	允许	高环境

(参考：Wikipedia 上的部署环境)

组级受保护环境名称

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

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

配置组级成员身份

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

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

有了此配置：

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

在组下保护关键环境

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

使用界面

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

使用 API

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

部署审批

受保护环境也可用于要求部署前进行手动审批。更多信息，请参见 部署审批。

故障排除

报告者无法运行部署到受保护环境的下游管道中的触发作业

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

有关支持 environment 关键字与 trigger 关键字的信息，请参见 此问题。