写在前面的话
在一个企业研发部门内部，可能存在多个运维人员，而这些运维人员往往负责不同的项目，但是有可能他们用的又是同一个 Jenkins 的不同用户。那么我们就希望实现一个需求，能够不同的用户登录 Jenkins 以后看到不同的项目。Jenkins 提供了简单的权限管理，我们可以在 系统管理 --> 全局安全配置 看到：
但是这里的权限配置太过简略，显然无法满足我们复制的需求，所以在这个时候引入了 Jenkins 的一个插件：Role-based Authorization Strategy
插件：Role-based Authorization Strategy
打开插件中心，我们可以搜索：
重启 Jenkins 以后，再度打开：系统管理 --> 全局安全配置 会发现多了我们刚刚插件的选项
我们选择该配置，同时在 系统管理 中出现了新的选项：
准备工作：
1. 将我们的项目复制成如下用于测试：
2. 新建 3 个测试用户：test / develop / product
打开：系统管理 --> 管理用户
最终用户格式：
配置权限：
打开：系统管理 --> Manage and Assign Roles
我们主要使用上面两种。一个用户想要进行操作必须要有两种角色，一种是全局，一种是 Project：
1. 创建角色：Manage Roles
2. 分配角色：Assign Roles
说明：我们这三个用户其实代表着三个不同的属性，为了区分我给他定义了三种不同角色。这样以后就可以给每个角色授权不一样的权限。
当然，我们这里就给了一个全部的只读权限，用户可以登录，并且修改自己的东西。
3. 创建项目角色：Manage Roles
4. 给用户分配项目权限：Assign Roles
说明：我们给用户分配不同的项目和权限，便于测试对比。
5. 查看权限效果：
test 用户登录后项目：
test 用户项目权限：
test 用户权限说明：test 用户登录后能看到 TEST 开头的项目，包括文件夹，但是对于项目，test 用户都只具有执行权限，而没有修改和配置的权限。
develop 用户登录后项目：
develop 用户项目权限：
develop 用户权限说明：可以看到，因为我们多配置了 Config 权限的原因，develop 相比于 test 用户对于分配给自己权限的项目多了修改配置权限。
product 用户登录后项目：
product 用户对于 TEST 项目权限：
product 用户对于 PRODUCT 项目权限：
product 用户授权说明：我们可以看到，PROCUDT 项目由于授权了 config 权限，所以用户能够修改，TEST 项目没用 config 权限，虽然同样是授权给了 product 用户，但是也是只有执行权限而已。
至此，基本的权限管理大致完成！
特别注意
在我们设置用户权限的时候，默认已经包含了管理员角色：
如果我们一不小心把这个勾去掉了，然后就炸了！
最终的解决办法是：
1. 停止 Jenkins。
2. 备份 /data/jenkins/jenkins-data/config.xml 配置文件。
3. 修改配置：
<useSecurity>true</useSecurity> # 改为 <useSecurity>false</useSecurity>
4. 删除权限配置：建议文件拿来了使用 nodepad++ 类似的工具修改
删除：<authorizationStrategy> 标签及其内部内容。
删除：<securityRealm> 标签及其内部内容。
5. 启动 jenkins，此时不需要用户名密码，查看设置：
默认没有启动安全，我们需要重新配置我们之前的东西！
小结
Role 插件相比于系统的虽然完善了不少，但是仍然在很多时候显得不那么只能，而且前端似乎并不友好。但没办法，这东西没得挑。
原文地址：https://www.cnblogs.com/Dy1an/p/11202544.html