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

GitLab 是一个全球知名的一体化 DevOps 平台，很多人都通过私有化部署 GitLab 来进行源代码托管。极狐GitLab ：https://gitlab.cn 是 GitLab 在中国的发行版，专门为中国程序员服务。可以一键式部署极狐GitLab。

更多关于极狐GitLab ：https://gitlab.cn 或者 DevOps 的最佳实践，可以关注文末的极狐GitLab 公众号。

学习极狐GitLab 的相关资料：

1. 极狐GitLab 官网：https://gitlab.cn
2. 极狐GitLab 官网文档：https://docs.gitlab.cn
3. 极狐GitLab 论坛：https://forum.gitlab.cn/
4. 极狐GitLab 安装配置：https://gitlab.cn/install
5. 极狐GitLab 资源中心：https://resources.gitlab.cn

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

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

 

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

 

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

 

 

 

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

 

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

 

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

广泛的访问排列

 

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

 

一致的CRUD模型

 

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

 

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

允许	描述
管理	对资源的完整 CRUD 操作。加上配置资源的设置。假设写入/查看/删除
写	添加或更新资源。假设视图
看	观看资源
删	删除资源。假设视图

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

允许	描述
管理	对对象（包括软件包仓库、代理、清理策略）进行 CRUD 操作以及管理设置
写	能够将容器、包或 terraform 模块推送到软件包仓库
看	能够查看、检索和提取存储库和映像上的软件包仓库对象和元数据
删	能够删除软件包仓库对象和元数据

删除默认角色依赖

 

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

 

建立自己的角色

 

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

 

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

 

从模板构建角色

 

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