如何使用极狐GitLab 实现最小权限访问？

极狐GitLab 是 GitLab 在中国的发行版，专门面向中国程序员和企业提供企业级一体化 DevOps 平台，用来帮助用户实现需求管理、源代码托管、CI/CD、安全合规，而且所有的操作都是在一个平台上进行，省事省心省钱。可以一键安装极狐GitLab，详情可以参考极狐GitLab 下载安装官网。

GitLab 中文版学习资料

驭码CodeRider 官网：https://coderider.gitlab.cn/
GitLab 中文版官网：https://gitlab.cn
GitLab 中文文档：https://docs.gitlab.cn
GitLab 中文下载安装：https://gitlab.cn/install

最小权限原则 (PoLP) 是一个概念，其中用户的访问权限应限制在他们完成各自角色所需的任务时所需的最低限度。通过实施 PoLP，你可以通过以下方式增强组织的安全态势，补充零信任：

减少攻击面：如果凭证遭到泄露，泄露将仅限于受损账户有权访问的路径。
防止人为错误：用户将无法执行其角色不需要的操作。
遵守合规性：SOC2 和 HIPAA 等多项合规性要求需要职责分离和最小特权最佳实践。
减少系统停机时间：通过阻止每个人访问软件开发生命周期 (SDLC) 的关键部分，可以减少停机的可能性。

极狐GitLab 提供了各种不同的功能，允许你自定义用户可以执行的操作，以帮助实现 PoLP。这些功能包括：

自定义角色和精细的安全权限：允许创建组织为某项特定功能设定的特定角色。
安全策略：允许创建策略，防止不安全的代码未经批准就合并到生产分支中，不管你的流水线如何定义，都能运行安全扫描。
分支保护和代码所有者：对某些分支施加进一步的限制以控制权限，例如谁可以合并、推送等到定义好的的分支。
合规流水线和框架：确定你的项目具有某些合规性要求或需要额外的监督，从而对应用它的项目强制执行流水线配置。

在这篇博文中，你将了解提到的每个功能、它们如何改善组织的安全状况以及如何实施它们。

定义角色和精细的安全权限

极狐GitLab 允许你创建自定义角色，这些角色将附加权限应用于基本角色，以满足组织的安全需求。可用的基本角色如下：

访客
报告者
开发者
维护者
所有者

每个基本角色会向用户应用一组特定的权限。基本角色对组成员、项目成员和项目功能应用不同的权限。例如，下表显示了哪些角色可以查看项目依赖列表：

请添加图片描述

依赖项列表也称为软件物料清单 (SBOM)，显示项目的依赖项以及有关这些依赖项的关键详细信息。只有那些积极参与项目的人才能看到存在哪些依赖项，以限制使用其依赖项对应用程序的任何利用，这是有道理的。

但是，在某些情况下，访客可能需要查看 SBOM 以协助组织实现合规性。通过使用自定义角色，可以创建一个具有访客角色的所有有限权限的新角色，此外，还可以添加查看项目依赖项列表的功能。因此，我们有一位访客协助我们遵守其工作所需的最低特权访问权限。

细化权限

从极狐GitLab 16.8 版本开始，可以将以下细化权限添加到任何基本角色：

查看项目代码
查看漏洞报告
更改漏洞状态
查看 SBOM
批准合并请求
管理项目/组访问令牌
添加/删除群组成员
归档/取消归档/删除项目
管理 Terraform 状态

我们将继续在每个极狐GitLab 版本中添加更细化的权限。

实施的先决条件

实现自定义角色的要求如下：

你在需要创建自定义角色的顶级群组中是拥有者角色
私有化部署的需要管理员权限
顶级群组需要具备极狐GitLab 旗舰版功能
具有 API 范围的个人访问令牌

要查看自定义角色的实际效果，需要：

顶级群组或其子群组内的私有项目
私有项目中的访客用户

当你为具有访客角色的用户启用自定义角色时，该用户将获得提升后的一些权限，因此：

将在私有化部署的极狐GitLab 中被视为付费用户

创建具有精细权限的自定义角色

现在你已经了解了使用精细权限实现自定义角色的好处，让我们在极狐GitLab 实例中实现它们：

在左侧边栏上，选择“搜索”或“转到”。
在极狐GitLab SaaS 中找到并选择你要在其中创建自定义角色的顶级组。
在极狐GitLab 私有部署版本中找到并选择管理区域。
选择设置 > 角色和权限。
在极狐GitLab 私有部署版本中，使用顶部下拉列表查找并选择要在其中创建自定义角色的顶级群组。
选择添加新角色。
以基本角色为模版，为本教程选择访客。
在角色名称下，输入自定义角色的标题。
在自定义角色的权限下，选择本教程的读取漏洞。
选择创建新角色。

创建自定义角色的界面
在这里插入图片描述

创建角色后，你应该能够看到新的自定义角色及其 ID、基本角色和权限。请务必保存 ID，因为当我们将自定义角色分配给来宾用户时将使用该 ID。

在这里插入图片描述

现在我们必须将自定义角色分配给群组或项目成员。这可以按如下方式完成：

邀请用户作为具有访客角色的直接成员加入创建自定义角色的顶级群组。
你也可以邀请他们加入顶级群组内的子群组或私有项目。
- 访客用户不应该看到他们被分配到的项目中的任何代码。
- 打开你的终端。
导出所需的环境变量：

你的具有 API 范围的个人访问令牌

$ export TOKEN=glpat-XXXXXXXXXXXX
$ echo $TOKEN
glpat-XXXXXXXXXXXX

我们将授予自定义角色的用户 ID。你可以通过向 User API 提供用户名来获取用户 ID。有关使用极狐GitLab API 的更多信息，请参阅REST API 文档。

$ curl "https://gitlab.example.com/api/v4/users?username=fjdiaz"
[{"id":4710074,"username":"fjdiaz","name":"Fern","state":"active","locked":false,"avatar_url":"https://gitlab.com/uploads/-/system/user/avatar/4710074/avatar.png","web_url":"https://gitlab.com/fjdiaz"}]

$ export USER_ID=4710074
$ echo $USER_ID
4710074

自定义角色的ID。你可以从自定义角色UI或成员角色API的ID列获取自定义角色ID。

$ export CUSTOM_ROLE_ID=1000782
$ echo $CUSTOM_ROLE_ID
1000782

你的群组或项目的 ID。你可以从组 UI或使用组 API获取组 ID。你可以从项目 UI或使用项目 API 获取项目 ID。

$ export GROUP_ID=10087220
$ echo $GROUP_ID
10087220

$ export PROJECT_ID=45738177
$ echo $PROJECT_ID
45738177

使用适当的群组或项目 API 将访客用户与自定义角色关联。
- 如果用户只需要一个项目角色，更新项目成员身份即可：

"Authorization: Bearer $TOKEN" --data '{"member_role_id": $CUSTOM_ROLE_ID, "access_level": 10}' "https://gitlab.example.com/api/v4/projects/$PROJECT_ID/members/$USER_ID"

* 如果用户只需要一个群组角色，更新群组成员身份即可：

$ curl --request PUT --header "Content-Type: application/json" --header "Authorization: Bearer $TOKEN" --data '{"member_role_id": $CUSTOM_ROLE_ID, "access_level": 10}' "https://gitlab.example.com/api/v4/groups/$GROUP_ID/members/$USER_ID"

现在，自定义角色已应用于访客用户，当他们登录时，他们可以看到“安全”选项卡中存在的漏洞仪表板。但请注意，他们仍然不允许查看源代码。

这很实用，因为它允许用户在无法更改代码库的情况下审核系统，这将 PoLP 应用于审核系统漏洞的人员。

安全政策

极狐GitLab 提供安全策略来帮助你实现最小权限访问。极狐GitLab 提供两种不同类型的安全策略：

扫描执行策略使项目维护人员和管理员可以放心地知道他们设置的扫描未被更改、更改或禁用。
合并请求批准策略可防止不安全的代码在未经适当批准的情况下合并到生产中。

以下是如何同时使用这两种策略类型来提供最小权限访问的一些示例：

取消开发人员禁用安全扫描程序的能力
消除开发人员合并不安全代码的能力

策略存储在与其应用的项目不同的存储库中，称为安全策略项目 (SPP)。这允许为 SPP 与应用程序存储库设置单独的权限，从而增强你分离职责和应用 PoLP 的能力。

在这里插入图片描述

要实施 SPP 中包含的策略，请将其链接到项目、子群组或群组。 SPP 可以包含多个策略，但它们是一起强制执行的。对群组或子群组强制执行的 SPP 适用于嵌套群组以下的所有内容，包括所有子群组及其项目。

安全策略可以通过策略管理 UI 以及 yaml 进行管理。使用策略编辑器，你可以创建、编辑和删除策略。

在这里插入图片描述

创建扫描执行策略

现在让我们看看如何创建扫描执行策略。在开始之前，请确保你已满足以下条件：

顶级群组具备旗舰版功能
创建/分配 SPP 的所有者角色
开发人员角色或更高级别的角色来创建/编辑/删除个人安全策略

我们将创建一个策略，自动对每个流水线运行 SAST 扫描，无论 .gitlab-ci.yml 中是否定义了 SAST 模板：

在左侧边栏上，选择“搜索”或转至并搜索要添加策略的项目。
在项目左侧边栏上，转到“安全”>“策略”。
选择新策略。
在“扫描执行策略”部分中，选择“选择策略”。
填写字段：
- 名称：政策名称
- 描述：策略的描述
- 策略状态：是否启用
- 行动：满足定义的条件时采取什么行动

在这里插入图片描述

条件：必须满足条件（触发流水线或按设定的时间表）才能发生操作。

在这里插入图片描述

按“配置合并请求”按钮。

现在策略已经创建，我们需要做的就是运行一个流水线来查看 SAST 是否存在，即使它没有在 .gitlab-ci.yml 中定义。

创建合并请求批准策略

现在让我们看看如何创建合并请求批准策略。在开始之前，请确保你已满足以下条件：

顶级群组具备旗舰版功能
创建/分配 SPP 的所有者角色
开发人员角色或更高级别的角色来创建/编辑/删除个人安全策略
安全扫描仪添加到项目中

如果任何安全扫描器与任何分支相比检测到漏洞，我们将创建一项需要项目维护人员批准的策略：

在左侧边栏上，选择“搜索或转至”并搜索要添加策略的项目。
在项目左侧边栏上，转到“安全”>“策略”
选择新政策
在“合并请求批准策略”部分中，选择“选择策略”。
填写字段：
- 名称：政策名称
- 描述：策略的描述
- 策略状态 ：是否启用
- 规则：发生某项操作（需要批准）必须满足的条件。

在这里插入图片描述

操作：只要满足规则中的条件（已定义的漏洞/检测到的许可证）就要采取的操作。

在这里插入图片描述

覆盖项目审批设置：如果选择，以下选项将覆盖项目设置，但仅影响策略中选择的分支。

在这里插入图片描述

按“配置合并请求”按钮。

现在策略已经创建，我们需要做的就是运行流水线，如果 SAST 检测到任何漏洞，则需要获得所选批准者的批准才能合并代码更改。合并请求批准策略可与所有极狐GitLab 安全扫描程序一起使用，包括许可证扫描。

在这里插入图片描述

分支保护和代码所有者

分支保护允许你对存储库中的特定分支施加额外的限制。这进一步加强了 PoLP 在一组特定分支上的交互。

例如，受保护的分支可以控制：

哪些用户可以合并到分支中
哪些用户可以推送到分支
用户是否可以强制推送到分支
对 CODEOWNERS 文件中列出的文件的更改是否可以直接推送到分支
哪些用户可以取消对分支的保护

应用分支保护

极狐GitLab 的所有层级和产品均提供分支保护。分支保护可以应用于单个项目或一组项目。你可以对所需角色应用分支保护以进行推送和合并，如下所示：

在左侧边栏上，选择“搜索或转到”并查找你的项目或群组。
选择设置 > 存储库。
展开受保护的分支。
选择添加受保护分支。
- 对于组，从分支文本框中输入分支名称或通配符。
- 对于项目，从分支下拉列表中选择要保护的分支。
从允许合并列表中，选择可以合并到此分支的角色。
从允许推送和合并列表中，选择可以推送到此分支的角色。
选择保护。

你现在应该看到受保护的分支已添加到列表中。

在这里插入图片描述

向群组添加分支保护需要所有者角色，向项目添加分支保护需要维护者角色或更高角色。

代码所有者

如果你想进一步限制开发人员可以对哪些文件进行更改，那么要实现的最佳功能之一是代码所有者。代码所有者允许你定义谁可以对代码库的部分做出专业变更。在代码所有者中定义好的文件和目录所有者将：

要求所有者在合并到受保护分支之前批准更改和合并请求
通过在其拥有的文件和目录上显示代码所有者名称来识别所有者

要设置代码所有者，请执行以下步骤：

在你的首选位置创建 CODEOWNERS 文件。
按照代码所有者语法参考在文件中定义一些规则。你可以配置所有符合条件的审批者的审批规则，并要求代码所有者对受保护的分支进行审批。
提交你的更改，并将其推送到极狐GitLab。

现在，在查看文件时，你可以看到特定文件的代码所有者是谁。

在这里插入图片描述

如果你实施代码所有者批准，则在创建合并请求时，代码所有者必须批准才能合并代码。

在这里插入图片描述

附加审批设置

在使用合并请求提交代码之前，可以应用其他批准设置。这些额外的批准设置如下：

阻止作者批准
阻止添加提交的用户批准
防止在合并请求中编辑审批规则
要求用户重新进行身份验证（密码或 SAML）才能批准

此外，每当添加提交时，你都可以：

保留批准
删除所有批准
如果代码所有者的文件发生更改，则删除其批准

要配置其他批准设置，你可以执行以下步骤：

在左侧边栏上，选择“搜索或转到“并查找你的项目。
选择设置 > 合并请求。
向下滚动到合并请求批准部分。
在“审批设置”下，选择你要应用的审批设置。
按保存更改按钮。

还可以通过执行以下步骤将这些应用到你的顶级组：

在左侧边栏上，选择“搜索或转至”并查找你的顶级组。
选择“设置”>“常规”。
展开合并请求批准部分。
在“审批设置”下，选择你要应用的审批设置。
按保存更改按钮。

通过利用这些批准设置，你可以确保代码始终受到未参与代码创建的人员的监督，从而防止利益冲突。

合规流水线和框架

你可以创建一个合规性框架，该框架是一个标签，用于标识你的项目具有某些合规性要求或需要额外的监督。该标签可以选择对应用它的项目强制执行合规性流水线配置。

请随意利用合规性框架演示组来查看合规性框架及其用法的示例。

创建合规流水线

要创建合规性流水线，你所需要做的就是创建一个新项目，该项目将存储我们希望在另一个项目中使用的 .gitlab-ci.yml 文件。新的合规性流水线项目可以与你将应用它的项目具有单独的权限。这是有益的，因为它可以防止开发人员对必须运行的流水线进行更改。

你可以看到我创建了以下流水线定义：

运行 SAST 安全扫描器
运行密钥检测扫描仪
运行 SOC2 合规性作业
运行我们将应用此流水线的项目中定义的原始流水线。这使得开发人员能够专注于实际的应用程序开发，而合规团队则能够专注于定义 SOC2 规则。

创建并应用合规框架

既然 SOC2 的合规流水线已经定义，我们必须定义一个合规框架并将其应用到我们的项目中。在这种情况下，我会将其应用到我的账号部门项目中。

要创建合规性框架标签，请执行以下步骤：

在左侧边栏上，选择“搜索或转至“并查找你的群组。
选择“设置”>“常规”。
展开合规性框架部分。
单击添加框架按钮。
创建新的合规框架并填充以下部分：
- 名称：你的合规框架的名称
- 描述：你的合规框架的描述
- 合规性流水线和配置：要运行的合规性流水线的位置。
- 背景颜色：合规框架标签的颜色

在这里插入图片描述