3. GitLab 权限模型基础
在评审 CI/CD 模板目录的权限边界之前，必须透彻理解 GitLab 的权限模型。该模型决定了谁可以读取、写入、审批或管理模板仓库中的文件与配置。本章从三个核心维度展开：用户角色、组权限继承与项目权限覆盖规则。
3.1 用户角色体系
GitLab 定义了五个内置角色，权限从低到高依次为：Guest、Reporter、Developer、Maintainer、Owner。每个角色在项目与组级别拥有不同的操作能力。
| 角色 | 权限等级 | 核心能力（项目级别） | 对 CI/CD 模板的影响 |
|---|---|---|---|
| Guest | 0 | 仅可查看公开项目的问题、讨论、里程碑 | 无法查看模板仓库代码，不能触发流水线 |
| Reporter | 10 | 查看代码、合并请求、流水线状态、下载制品 | 可浏览模板内容，但无法提交修改或触发 CI |
| Developer | 20 | 推送分支、创建合并请求、触发流水线、查看日志 | 可修改模板文件、提交 MR、触发 CI 作业 |
| Maintainer | 30 | 合并 MR、管理 CI/CD 变量、配置保护分支、管理 Runner | 可合并模板变更、修改 CI 配置、管理模板目录权限 |
| Owner | 50 | 删除项目、转移项目、修改可见性、管理所有设置 | 拥有模板仓库的完全控制权，可撤销任何权限 |
关键边界：在模板目录权限评审中，Developer 角色是默认的“写入边界”。任何超过 Developer 权限的变更（如直接合并到主分支、修改 CI/CD 变量）必须由 Maintainer 或 Owner 执行。
3.2 组权限继承模型
GitLab 的组（Group）是组织权限的核心单元。子组与项目会自动继承父组的权限设置，形成树状继承链。继承规则遵循“就近原则”：越靠近子节点的权限设置优先级越高。
继承路径示例：
根组
如果根组将 Developer 角色设为“允许写入”，则子组与项目默认继承该设置，除非在子组或项目级别显式覆盖。
根组
acme → 子组 acme/security → 项目 acme/security/ci-templates如果根组将 Developer 角色设为“允许写入”，则子组与项目默认继承该设置，除非在子组或项目级别显式覆盖。
3.3 项目权限覆盖规则
当组级权限无法满足特定项目的安全需求时，GitLab 允许在项目级别覆盖继承的权限。覆盖规则遵循以下优先级：
- 项目显式设置 > 组继承设置：项目级别的角色权限配置会完全替代父组传递下来的设置。
- 最小权限原则：覆盖时通常降低权限（如将 Developer 降为 Reporter），而非提升权限。
- 继承链中断：一旦项目设置了显式权限，该项目的子模块（如容器镜像、Package 注册表）不再受父组权限变更影响。
⚠️ 常见陷阱：在模板目录评审中，如果某个模板项目被设置为“仅 Maintainer 可写”，但父组后来将 Developer 权限提升为 Maintainer，该项目的权限不会自动升级——因为项目级别的显式覆盖阻断了继承链。务必在评审清单中记录所有显式覆盖的项目。
3.4 权限模型在模板目录中的应用
结合上述模型，在 CI/CD 模板目录的权限边界评审中，需要重点关注以下场景：
| 场景 | 推荐角色 | 评审要点 |
|---|---|---|
| 模板仓库只读访问 | Reporter | 确保外部团队可查看模板，但无法修改 |
| 模板贡献与 MR 提交 | Developer | 允许推送分支、创建 MR，但禁止直接合并到主分支 |
| 模板合并与发布 | Maintainer | 控制合并权限，管理版本标签与 CI/CD 变量 |
| 模板仓库全局管理 | Owner | 仅限平台管理员，负责权限审计与仓库删除 |
3.5 权限边界评审清单
基于上述模型，在模板目录权限边界评审中，应逐项检查以下内容：
- 角色映射：确认每个模板仓库的成员角色是否符合最小权限原则。
- 继承链完整性：从根组到项目，逐层验证权限继承是否按预期生效。
- 显式覆盖记录：标记所有在项目级别覆盖了组权限的仓库，并评估其合理性。
- CI/CD 变量权限：检查哪些角色可以查看或修改模板仓库的 CI/CD 变量（通常仅限 Maintainer）。
- 保护分支规则：确认主分支是否设置为“仅 Maintainer 可合并”，防止 Developer 绕过 MR 直接推送。
实践建议：在评审报告中，使用“权限矩阵表”列出每个模板仓库的组继承权限、项目显式权限、实际生效权限，以及对应的风险等级。这有助于快速定位权限过宽或过严的边界点。