如何用自定义角色定制极狐GitLab 访问权限

了解自定义角色的当前功能以及未来的功能，包括初始权限分组和默认角色的模板。

在极狐GitLab中，我们知道我们有一个大问题需要解决。我们现有的默认用户角色正在成为用户的障碍。默认角色（如访客、报告者、开发人员、维护者和所有者）提供一组无法自定义的预定义权限。用户被迫将其特定需求融入现有角色，从而导致访问过于宽松（存在安全风险）或特权不足（需要管理员开销暂时提升用户的权限才能执行任务），并记得事后将他们调回正常角色。

在 15.9 版本 中，我们发布了极狐GitLab 中可自定义角色的第一个迭代。它允许客户做一件简单的事情：让访客用户能够查看代码，而无需占用座位。我们的希望是让我们的客户能够根据需要为访客角色添加更多权限，同时保留终极订阅的免费访客用户的好处。

我们在一年前发布了 MVC，因此我们希望提供有关可定制角色方面所取得的进展的最新信息以及我们的发展方向的想法。

看看自定义角色的下一个迭代

当我们构建自定义角色和权限的下一个迭代时，我们从 MVC 收集了很多反馈。已发现的两个常见主题是：

减少开发人员、维护人员和所有者角色的特权

广泛的访问排列

以下是我们计划如何应对这些挑战。

一致的CRUD模型

如果您在 Google Cloud Platform (GCP) 或 Kubernetes 中设计了基于角色的访问控制 (RBAC)，您可能会乐意看到用户对于访问资源的可预测执行权限。随着我们继续为自定义角色构建下一个权限分组，这些权限将遵循一致的创建、读取、更新和删除 (CRUD) 模型，以便您可以以可预测的方式设计组织内的资源访问权限。

如果我们检查下表，“管理”将被指定为部门或组织中的少数几个，而“写入”和“查看”将是该资源的常见贡献者。

下面是与软件包仓库相关的权限的具体示例。虽然该表是粗粒度的，因为它首先将所有软件包仓库类型分组在一起，但随着时间的推移，通过根据请求提取每个软件包仓库类型，该表可以变得细粒度。

删除默认角色依赖

在自定义角色创建过程中，从基本默认角色开始可能是添加权限的快速方法，但当仅减少维护者或所有者的一两个权限时，它会受到限制。下一次迭代将允许您构建自己的自定义角色，而无需默认角色的预定义权限，从而实现最大的灵活性。

建立自己的角色

在系统中构建自定义角色应考虑排列数量，同时隔离严格环境中的访问权限。当我们对这些资源进行分组时，我们考虑到了广泛的主题，包括项目管理、开发、安全和运营。

下面是一个具有适用于开发人员的权限选择的分组示例。随着时间的推移，这些资源组可能会根据请求变得更加精细。

从模板构建角色

您可能已经体验过构建权限集作为简化用户访问分配的起点。在构建自定义角色时，您可以从一个模板开始，该模板从默认角色或特定用户类型（例如项目经理）复制预定义的权限。