Jenkins 构建任务的权限管理主要有两种思路:基于角色的权限控制(RBAC) 和 项目矩阵授权。前者更适合团队规模较大、需要按项目或命名规则批量管理的场景;后者则适合对单个任务进行精细的按人授权。
🔑 核心概念:认证与授权是两回事
在配置权限前,需要先明确:认证(Authentication) 解决"你是谁",授权(Authorization) 解决"你能做什么"。我们这里讨论的构建任务权限属于授权范畴。
无论选择哪种方案,首先都需要进入 Manage Jenkins → Configure Global Security,勾选 Enable security ,并选择一个安全域(Security Realm)(如 Jenkins 自有用户数据库、LDAP 等)来管理用户身份。
方案一:基于角色的权限策略(RBAC,推荐)
这是最常用也最灵活的方案,核心是 "角色 → 权限 → 用户" 的绑定关系。需要先安装 Role-based Authorization Strategy 插件。
配置步骤:
- 启用策略 :在全局安全配置中,将 Authorization 选为 Role-Based Strategy。
- 定义角色 :进入
Manage Jenkins→Manage and Assign Roles→Manage Roles。这里分为三类角色:- Global roles(全局角色) :如
admin(所有权限)、readonly(仅Overall/Read)。 - Item roles(项目角色) :这是管理构建任务权限的关键。你可以用正则表达式 匹配任务名称,来实现批量授权。
- 例如,正则
team-a-.*可以匹配所有以team-a-开头的任务。为这个角色分配Job/Build、Job/Read、Job/Configure等权限,那么所有team-a-前缀的任务就自动归这个角色管了。
- 例如,正则
- Node roles(节点角色):用于管理 Agent 节点的权限。
- Global roles(全局角色) :如
- 分配角色 :在
Assign Roles页面,把具体的用户或用户组(如 LDAP 组)添加到对应的角色下。
注意 :全局角色会覆盖项目角色。如果你在全局角色中给了某个用户
Job/Read,那么他将无视项目角色的限制,能看到所有任务。
方案二:项目矩阵授权(Matrix Authorization)
这个方案更直接,适合不需要按名称批量管理 ,而是希望对特定任务单独指定人员的场景。需要安装 Matrix Authorization Strategy 插件。
配置步骤:
- 全局配置 :在全局安全配置中,选择 Project-based Matrix Authorization Strategy ,并在矩阵中先为所有用户分配基础的
Overall/Read权限(否则他们看不到任何内容)。 - 任务级配置 :进入具体构建任务的
Configure页面,在General选项卡下找到 Enable project-based security。 - 精细授权 :在这里,你可以针对这一个任务 ,为特定用户勾选
Build、Configure、Read等权限。
这种方式的好处是控制粒度最细,但任务多的时候管理起来会比较繁琐。
"项目矩阵授权"的配置分为两步:全局开启策略 ,再针对具体任务授权。
🔧 第一步:全局开启策略
进入 Manage Jenkins → Configure Global Security,在 Authorization 部分选择 Project-based Matrix Authorization Strategy。
选择后,下方会出现一个全局权限矩阵。这里有一个关键步骤:必须为需要访问的用户或用户组勾选 Overall/Read 权限。如果漏掉这一步,用户即使被授予了任务权限,也可能因为看不到 Jenkins 主界面而无法操作。
安全提示 :不要给
anonymous用户授予任何权限。修改授权策略前,建议保留一个管理员会话,防止配置错误导致自己被锁在外面。
📋 第二步:为具体任务配置权限
进入任意构建任务的配置页面(Configure),在 General 选项卡下找到 Enable project-based security 并勾选。
此时会展开一个任务专属的权限矩阵。在 Inheritance strategy(继承策略) 下拉框中,选择权限的继承方式:
- Inherit permissions:默认选项,任务权限会叠加全局配置的权限。
- Inherit global configuration only:只继承全局权限,不继承父文件夹的权限,适合文件夹内的任务独立控制。
- Do not inherit permissions:最严格,只使用当前任务明确指定的权限(管理员除外)。
选好继承策略后,在矩阵中添加用户或组,按需勾选权限。对于只需要构建的用户,通常至少需要 Job/Read 和 Job/Build ;如果还需要取消构建,再加 Job/Cancel。
⚠️ 一个重要的安全边界
使用项目矩阵授权时,需要留意一个隐含风险:被授予 Job/Configure 权限的用户,可以自行修改这个任务的权限设置,包括给自己添加其他权限 。因此,只应把 Configure 权限授予真正需要管理该任务配置的人。