用户与权限管理

从第一性原理出发，GitLab 的权限管理本质上是在解决一个经典的安全问题：在复杂的现实团队协作中，如何以最低的管理成本，实现细粒度的基于角色的访问控制（RBAC），并控制操作的“爆炸半径”。

如果把 GitLab 想象成一个文件系统：

  • Group（群组） 就是文件夹。它是用来做逻辑隔离和策略下发的边界。
  • Project（项目） 就是文件（实际存放代码和流水线的地方）。
  • User（用户） 就是实体。

GitLab 设计了一条铁律：权限向下继承，且（在开源版中）不可在子层级被削弱。

这意味着，如果你在一个 Group（父文件夹）中赋予了某人较高的权限，他将自动拥有该 Group 下所有 Project（子文件）的同等权限。你只能在具体的 Project 中叠加他的权限，而不能剥夺他从 Group 继承来的权限。

五种核心角色（Role）的本质区别如下：

  1. Guest（访客）：只能看 Issue 和 Wiki，看不到代码（私有项目下）。
  2. Reporter（报告者）：可以拉取（Pull）代码，但不能推送（Push）。适合 QA 查阅代码或非开发人员查看代码。
  3. Developer（开发者）：主力干活的。可以提交代码，创建分支，发起 Merge Request。但不能直接推送到受保护的分支（如 main）。
  4. Maintainer（维护者）：项目的管家。可以合并代码、修改项目设置、配置 CI/CD 变量。
  5. Owner（所有者）：最高权限，通常只有在 Group 级别才有这个角色，可以管理账单、删除群组等。

动手实验：验证“权限继承”与“爆炸半径”

为了彻底搞懂这套逻辑，我们不用理论，直接在你的 gitlab-ce:18.6.6 上跑一个沙盒实验。

实验目标：

模拟一个真实公司的部门架构，验证成员如何通过加入不同的“组织层级”来自动获取“代码库”的访问权。

第一步：搭建“文件夹”结构（Group & Project）

  1. 使用管理员账号（通常是 root）登录 GitLab。
  2. 点击左侧导航栏的 + 号，选择 New group -> Create group。
    • Group name 填入：infrastructure-team（基础设施团队）
    • Visibility level 选择：Private（私有）
  3. 进入刚刚创建的 infrastructure-team 群组，点击 New project -> Create blank project。
    • Project name 填入：k8s-manifests（K8s 部署清单）
    • 取消勾选 “Initialize repository with a README”（先建个空库即可）。
  4. 回到首页，再建一个独立的项目（不放在任何 Group 下，直接属于 root 用户个人）：
    • Project name 填入：hugo-blog-theme
    • Visibility level 选择：Private。

第二步：创建虚拟“实体”（Users）

  1. 进入 Admin Area（左下角扳手图标，或者顶部搜索栏搜索 Admin）。
  2. 进入 Users -> New user。
  3. 创建用户 A（代表核心骨干）：
    • Name: Alice_DevOps
    • Username: alice
    • Email: alice@example.com
    • （创建后点击 Edit 给她设置一个密码，方便一会登录）
  4. 同样的方法，创建用户 B（代表外包实习生）：
    • Name: Bob_Intern
    • Username: bob
    • Email: bob@example.com
    • （同样设置一个密码）

第三步：分配权限（核心实验）

  1. 给 Alice 分配高层级权限：
    • 进入刚才的 infrastructure-team 群组页面。
    • 点击左侧的 Manage -> Members。
    • 点击 Invite members，搜索并选中 Alice_DevOps。
    • Role 选择 Maintainer，点击邀请。
  2. 给 Bob 分配底层级权限：
    • 进入 k8s-manifests 项目页面（注意，不是群组页面）。
    • 点击左侧的 Manage -> Members。
    • 邀请 Bob_Intern，Role 选择 Reporter。

第四步：切换视角，见证奇迹

现在，我们要分别扮演 Alice 和 Bob 来验证结果。

  1. 登出 root，使用 Alice 的账号登录。
    • 观察 1：在主页的 Projects 列表中，Alice 会直接看到 infrastructure-team / k8s-manifests 项目。为什么？因为权限向下继承。 她是 Group 的 Maintainer，自动成为了该 Group 下所有项目的 Maintainer。
    • 观察 2：她看不到 hugo-blog-theme。因为那个项目在另一个“平行宇宙”里，没有交集。
  2. 登出 Alice，使用 Bob 的账号登录。
    • 观察 1：Bob 也能在主页看到 k8s-manifests 项目。
    • 观察 2：点进项目，Bob 只有拉取代码的权限，找不到配置 CI/CD 变量的地方，也没有修改项目设置的菜单。
    • 观察 3：如果未来 root 用户在 infrastructure-team 下新建了一个 ansible-playbooks 项目，Bob 是看不到的，因为他的权限被严格限制在了 k8s-manifests 这个单一文件的“爆炸半径”内；而 Alice 会自动获得新项目的管理权。

实验总结（记录到你的笔记中）： 不要在 Project 级别挨个加人，那会演变成运维灾难。 最佳实践是：根据现实中的组织架构建立 Group 和 Sub-group，把人拉进 Group 里赋予基础角色（如 Developer），然后把项目放在对应的 Group 下让其自动继承。

完成这个实验后，告诉我你这边的现象是否符合预期？如果在配置中遇到哪个按钮找不到，随时告诉我。接下来如果你觉得没问题，我们可以进入模块二：代码托管与版本控制的底层逻辑。