CentOS 上 Jenkins 团队管理实操指南
一 身份与认证
- 在 CentOS 上部署好 Jenkins 后，进入 Manage Jenkins → Configure Global Security 配置认证方式。小规模团队可直接使用 Jenkins’ own user database 并在 Manage Users 中创建账号；若需统一账号，可接入 LDAP（安装 LDAP 插件后配置服务器信息）。注意：切换认证方式（如从本地库切到 LDAP）可能导致既有授权配置丢失，务必先备份并在变更前保留一个具有 Overall/Administer 权限的可用管理员会话。
二 授权模型与最小权限
- 安装并启用 Role-based Authorization Strategy 插件，在 全局安全配置 将授权策略切换为 Role-Based Strategy，随后通过 Manage and Assign Roles 完成“角色→权限→用户/组”的绑定。常用权限粒度包括：
- Overall：如 Administer、Read（全局读/管理员）。
- Job：如 Create/Delete/Configure/Read/Build/Cancel（任务生命周期）。
- Run：如 Delete/Update/Replay（单次构建记录操作）。
- View：视图的增删改查。
- SCM：如 Trigger（由代码变更触发构建）。
- Agent/Node：节点管理权限。
- Credentials：凭据管理权限。
- 建议采用“全局角色 + 项目角色 +（可选）节点角色”的三层模型，遵循最小权限原则，仅授予完成工作所需的最小权限集合。
三 多团队隔离与权限分配示例
- 命名规范：团队内任务统一前缀，如 team-a-、team-b-、prod- 等，便于用正则进行项目级授权。
- 全局角色（示例）：
- admin-role：授予 Overall/Administer（全权）。
- read-only-role：授予 Overall/Read（登录后只读）。
- ops-role：授予 Overall/Read、Job/Read/Configure、必要的 Agent/ 权限（可管理任务与节点，但不可改系统设置）。
- 项目角色（示例，使用正则匹配任务名）：
- team-a-dev：Pattern 为 team-a-.*，授予 Job/Build、Job/Read、Job/Configure、Job/Cancel。
- team-b-dev：Pattern 为 team-b-.*，权限同上。
- （可选）team-prod-ops：Pattern 为 prod-.*，仅授予 Job/Read、Job/Cancel，禁止配置与删除，用于生产值守。
- 角色分配（示例）：
- admin → admin-role。
- ops → ops-role + read-only-role。
- dev-a1/dev-a2 → team-a-dev + read-only-role。
- dev-b1/dev-b2 → team-b-dev + read-only-role。
- 验证要点：以不同账号登录，确认团队 A 只能看到并操作 team-a-* 任务，团队 B 只能操作 team-b-* 任务，且均受限于只读或禁止配置/删除的边界。
四 视图隔离与项目安全
- 使用 视图（View） 按团队或项目聚合任务，提升可见性与导航效率；视图仅影响展示，真正的权限边界仍由“项目角色 + 权限矩阵”控制。
- 对敏感任务可在任务 General → Enable project-based security 中进一步细化到“用户/组”的 Job 级别权限（如仅允许构建与查看），作为基于角色的补充手段。
五 企业级增强与运维建议
- 接入 LDAP 统一账号后，可在 Manage and Assign Roles 中直接对用户或组分配角色，实现集中身份与细粒度授权的统一治理。
- 分布式协作建议：为不同团队或环境准备带标签的 Agent/节点，在 Manage Nodes and Clouds 添加节点，并在任务/Pipeline 中通过 label 调度，实现资源隔离与并行构建。
- 安全变更流程：任何涉及 Security Realm 或 Authorization 的变更，务必保留一个 admin 会话，先小范围验证后再推广；变更前导出或备份 config.xml 等关键配置。