Jenkins GitLab 单点登录、项目矩阵授权策略
建设目标
构建一个 统一、规范、安全、可扩展 的发布平台，满足以下目标：
- 支持多项目并行使用，项目之间权限严格隔离
- 通过 GitLab 单点登录，避免用户双重维护
- 权限最小化，授权清晰
- 项目自治，减少平台管理员日常介入成本
- 支持项目规模扩展（用户 200+、项目数持续增长）
总体架构
核心组件
| 组件 | 作用 |
|---|---|
| GitLab | 用户身份源、组管理、代码仓库 |
| Jenkins | 统一发布平台 |
| Jenkins插件：GitLab Authentication plugin | 实现 GitLab SSO 登录 |
| Jenkins插件：Matrix Authorization Strategy Plugin | 实现细粒度授权（全局 / 文件夹 / Job） |
| Jenkins插件：Folder Plugin | 按项目文件夹隔离，方便权限管理 |
认证与用户管理设计
GitLab 单点登录（SSO）
- Jenkins 不本地维护任何用户
- 所有用户通过 GitLab OAuth 登录 Jenkins
- Jenkins 用户名 = GitLab username（保持唯一性）
收益：
- 用户账号由 GitLab 统一管理
- 避免 Jenkins 账号残留
GitLab 的群组方便在 Jenkins 上分配权限
GitLab 组作为权限载体
- 不直接给个人授权，优先授权 GitLab 组
Jenkins 权限配置中仅引用：
- GitLab Group
- 少量特权用户（如项目管理员）
项目与 Job 组织结构
项目级文件夹模型
设计原则：一个项目 = 一个 Jenkins Folder
Jenkins
├── project-a/
│ ├── app1
│ ├── app2
│ └── app3
├── project-b/
│ ├── app1
│ └── app2文件夹的职责
- 项目 Job 的唯一容器
- 项目权限边界
- 项目管理员的管理单元
禁止：
- 禁止在 Jenkins 根目录直接创建 Job
- 禁止跨 Folder 复用 Job（避免权限穿透）
权限模型设计
授权策略配置
Jenkins 全局授权策略：
授权策略：项目矩阵授权策略
| 对象 | 权限 |
|---|---|
| 匿名用户 | 无 |
| Authenticated Users | Overall → Read |
| 平台管理员 | Overall → Administer |
⚠️ 普通用户 不允许 看到非授权项目
项目级（文件夹）授权策略：
启用：Enable project-based security
项目基础用户组（GitLab Group）
示例：crm
适用对象：
- 项目开发
- 测试
项目管理员
示例：陈日志
职责：
- 维护项目 Job
- 管理项目成员权限
权限最小化原则落实方式
默认：给项目组授予 Job 的 Read + Build + Cancel 等基础权限
- 基础权限尽量授权给「组」
升权：
- 仅对明确职责人员授予更高的权限
不允许：
- 不允许直接授予 Overall → Administer
- 不允许在 Global 级别开放 Job 管理权限
项目管理员机制
项目管理员来源
- 通常为该项目的运维或项目开发负责人
- 由平台管理员在项目初始化时指定
项目管理员的权限边界
- 仅限该项目 Folder
- 无法影响其他项目
- 无法修改 Jenkins 全局配置
凭证与敏感信息管理
Credentials 使用原则
- 使用 Folder Scoped Credentials
- 禁止使用 Global Credentials（除非全局凭证）
权限控制
- 项目管理员：授予凭证的创建、删除、更新、查看等权限
- 普通项目成员：无凭证管理权限
风险与注意事项
常见风险
| 风险 | 对策 |
|---|---|
| 项目管理员误删 Job | 开启 Job 配置备份 |
| 权限配置混乱 | 统一模板 + 规范初始化流程 + 平台管理员/安全员定期核查 |
| 人员离职权限残留 | 依赖 GitLab SSO |
初始化流程
新项目接入流程：
- GitLab 创建项目组
- Jenkins 创建 Folder
- 绑定 GitLab 组权限
- 指定项目管理员