跳到主要内容

用户与权限管理

Jenkins 默认允许匿名访问，生产环境必须关闭。权限管理要回答三个问题：谁能登录？谁能在哪个文件夹/Job 上做什么？凭证谁能读？

本篇目标：能配置基于 Folder 的权限隔离，理解 Matrix 授权矩阵，并完成 LDAP/OAuth 对接。

1. 安全基线​

Jenkins 的安全配置在 Manage Jenkins → Security：

配置推荐值
控制器安全（CSRF）启用，默认即可
代理请求（代理的路径外访问）只允许固定代理目标（外部工具回连）
安全领域（Authentication）LDAP / SSO，至少禁用匿名注册
授权策略（Authorization）Matrix 授权或 Role-based，禁用"任何人均可做任何事"
标记格式Jenkins 专有（不允许任意 HTML/JS 注入）
两大默认风险
  1. 匿名用户默认有读权限——企业内网也建议收紧，至少把整体只读关掉；
  2. /script（脚本控制台） 是管理员后门，任何有 Overall/Administer 的人都能执行任意 Groovy，等于拿到 Master 全部权限。不要给普通用户此权限。

2. Folder 与权限隔离​

安装 Folders 插件（一般默认），用文件夹按团队/项目组织 Job，并把权限隔离到文件夹粒度。

Jenkins
├── platform/                        # 平台团队文件夹
│   ├── build-base-image
│   └── deploy-nginx
├── order-service/                   # 订单团队文件夹
│   ├── build
│   ├── test
│   └── deploy-prod
└── payment-service/                 # 支付团队文件夹

对文件夹 order-service 授权：

Manage Jenkins → Manage Folders → order-service → Security
启用"给子 Job 单独授权"
添加：order-dev 团队 → 该文件夹下 Job 的 Build / Read / Workspace
      order-ops 团队 → 额外加 Credentials（仅指定凭证）与 Configure

3. 授权策略：Matrix 与 Role-based​

3.1 Global Matrix Authorization Strategy​

内置矩阵策略，用 权限:用户/组 表格勾选：

权限项含义
Overall/Read能看到顶层和系统信息
Overall/Administer管理员（含脚本控制台）
Job/Read、Job/Build、Job/Configure查看 / 触发 / 修改 Job
Credentials/View、Credentials/Create、Credentials/Update查看 / 新建 / 修改凭证
Agent/Connect、Agent/Configure连接 / 配置 Agent
View/Read、View/Configure查看 / 配置视图

3.2 Role-based Authorization Strategy（RBAC）​

团队和角色多时用 Role Strategy 插件：

全局角色：admin / developer / viewer
项目角色：order-developer → order-*/ 下 Build+Read

角色定义后，把用户或 LDAP 组绑定到角色，再配合 Folder 隔离使用。

最小权限原则

给普通用户：Overall/Read（可选）+ Job/Read + 其负责 Job 的 Build/Configure + 需要的 Credentials/View。不要轻易给 Overall/Administer。

4. 与 LDAP / OAuth 对接​

4.1 LDAP（企业通用）​

Manage Jenkins → Security → Security Realm → LDAP
服务器：ldap://ldap.company.com:389
根 DN：dc=company,dc=com
用户搜索：uid={0},ou=People
组搜索：cn=jenkins-*,ou=Groups

配置后，Jenkins 用户来自 LDAP，离职即无法登录。配合 RBAC 角色绑定到 LDAP 组，实现"入职自动有权限、离职自动收回"。

4.2 OAuth / OIDC​

安装 GitLab Authentication 或 GitHub Authentication 插件：

Security Realm → GitLab Authentication
GitLab 服务器 URL：https://gitlab.company.com
Application ID / Secret：在 GitLab 中创建 OAuth Application 获取

用户用 GitLab 账号登录，与仓库权限天然对应。注意配置回调 URL 为 https://<jenkins>/securityRealm/finishLogin。

4.3 本地用户兜底​

授权策略中保留本地管理员账号
Security Realm → Jenkins 专有用户数据库

即使 LDAP 故障，也要有本地管理员可登录。建议锁定为 2 个或更少，密码放入密码管理器。

5. 凭证可见性隔离​

凭证与权限要联动：权限模型决定"谁能看到凭证"，凭证本身还要在 Folder 或全局层做可见性控制。

全局凭证：供所有 Job 使用（如镜像仓库账号、GitLab Token）——只给管理员可更新
文件夹凭证：仅该团队可见（如该服务的 DB 密码）

审计凭证读取：

# 打开"凭证使用审计"（Credentials Binding 插件 + Audit Trail 插件）
# 在 Manage Jenkins → Security → Audit Trail 中记录 credential 读取事件

6. 练习与验收​

练习 A

  1. 关闭匿名访问，创建 admin 和 developer 两个账号
  2. 安装 Role Strategy 插件，配置 developer 只能 Build 指定 Job，不能 Configure
  3. 验证 developer 无法进入系统管理

练习 B

  1. 创建两个 Folder（team-a、team-b），各放一个 Job
  2. 给 team-a 的账号只授权 team-a/* 的 Job/Read + Build
  3. 验证 team-a 账号看不到 team-b 的 Job

验收清单

  • 关闭了匿名访问，禁用"任何人均可做任何事"
  • 会使用 Matrix 授权或 RBAC 做最小权限
  • 会用 Folder 做团队级 Job 隔离
  • 能对接 LDAP 或 OAuth，保留本地管理员兜底
  • 知道 /script 脚本控制台是管理员专属高危入口
  • 凭证可见性按全局/文件夹分层控制

下一篇：凭证管理。