jenkins项目矩阵授权和Role-Based Stategy
作者：互联网
（1）jenkins全局安全配置 -- 【授权策略】 -- 【项目矩阵授权策略】
（2）开发使用账号，针对A项目的授权矩阵：
现在问题来了，A项目上线后，生产环境的发布权限要收回来，也就是测试元老、开发使用账号不应该再有A项目生产环境的发布权限了。开发使用账号处理起来很方便，直接去掉生产环境下的所有任务的矩阵即可，去掉“x”
而测试这个账号，貌似处理不了，因为如果从全局项目矩阵授权入手，会导致其他项目的发布权限都被收回去了（项目B、C、D等都看不到了），能看到是因为开了视图的“Read”权限。
我当时想到的是，如果针对A生产视图的任务不可见，只能在除A生产视图任务的其他所有任务下，配个针对每个项目粒度控制的矩阵授权，也就是开发使用账号在上面（2）的配置。
这个工作量很大：jenkins任务，粗略统计接近400个。去掉A生产6个任务，也有300多个，一个个在任务里面配置测试元老账号的矩阵。。。
当时因为领导一直催这个需求，所以临时处理办法：
a）先改掉测试元老账号的jenkins登录密码，不让测试人员使用
b）把开发账号给测试用（已去掉生产环境视图任务），
c）再建一个账号：xxx生产，只有生产环境发布权限。
二、测试研究
查了下资料，如果要实现控制用户只有部分视图权限，通篇都是说需要用基于角色进行授权（Role-Based Stategy）。这篇是我看了一堆资料感觉比较写的比较好的文章：https://blog.csdn.net/jxllove1120/article/details/122316432
在公司内网虚拟机测试了一轮，踩过不少坑，而导致前前后后恢复了几次快照还原。eg，下图是我进行全局角色授权做的操作，连admin用户都登不上了，原因被jenkins的bug害的，以为这个“No type prefix” 报错是我添加错了，于是直接删掉搞到登不上了。 注意：这个报错不用管，不影响使用
详细测试过程不细说，只说下重点。
1、jenkins授权策略切换过程中，会导致原授权策略配置失效。
假设原来配置了项目矩阵授权策略，如果要换成：Role-Based Strategy策略（下面我都简单说成基于角色授权策略），从勾选保存这个配置后，到又想重新切回到项目矩阵授权策略，那么，这个项目矩阵授权策略是完全被清掉的。
这个还没那么心疼，如果是配了一堆角色授权策略，临时多手勾了项目矩阵策略保存，呵呵，等你的就是无尽的后悔~~~
2、角色授权策略 vs 项目矩阵授权策略
（1）角色授权策略
a）管理角色
在管理角色（Manage Roles）设置Global roles，给全局jenkins某些权限；再配置Project roles，个性化地定制你想匹配的任务名，前提是这些任务名有一个规范的英文前缀，使jenkins能利用正则表达式去匹配。
注意： 中文任务名无法匹配
b）分配角色
最后给新建好的用户分配 Global roles 和 Project roles 的权限
（2）角色授权 vs 项目矩阵
角色授权：前期配置全局角色权限（Global roles）和项目角色权限（Project roles）比较繁琐，但配置好后续很方便：对公司不同部门、人员授权及权限回收，修改权限等等。本人认为，适用于后续权限经常变动的情况。
项目矩阵：前期配置简单容易，但配置好后续变更非常麻烦，麻烦在于需要深入到每个任务里改任务的权限矩阵！！！授权和回收权限也很麻烦，譬如我临时把生产发布权限的账号给测试人员自己去发布项目，等回收的时候只能通过管理员修改该账号密码，下次再授权给一个新密码登录去发布。再退一步来说，生产发布只给我和一个后端开发，要发布找我们俩。本人认为，该策略，适用于后期基本不用修改配置、权限的情景。
就我们公司而言，如果从项目矩阵切换到角色授权，风险大自不必说，内网跟线上服务器环境毕竟不同嘛~~~
线上jenkins环境所在的服务器太重要了，有所有项目的gitlab代码，nginx入口转发，还有某些项目的前端静态目录，几个tomcat，我内网测试的时候都恢复好过几次快照，因为单纯备份jenkins的config.xml做覆盖恢复，并重启jenkins服务，恢复不了；线上jenkins如果被我配置错了，云上的服务器恢复快照是需要停机的。而且有些服务还比较脆弱，关了不一定能正常开起来。
所以如果要改（其实我愿意冒着被祭天的风险，支持整改），建议、必须花钱来以防万一。先利用一台按量付费的测试机，将这个jenkins环境的快照导过去，配置好之后，再抄回到正式那台jenkins服务器上。
配置是一个问题，另外一个麻烦地方，就是原来那些jenkins建的任务需要重命名或者重建，因为起名字的时候都非常不规范：中文名、年月日开头的，或者名字中间靠中文来区分不同环境的。
三、完成需求
我昨晚失眠想了下，测试元老那个账号什么任务都能发布，就差个生产环境视图的任务是不开放的，把这个账号删掉实在可惜（我不仅对离职测试元老人不舍得，他使用的账号也不舍得，啊哈哈）。另外，项目矩阵策略其实挺适合小公司的，人数量少，管理账号也少，后期权限改动差不多。
既然开发使用的账号是通过全局项目矩阵+任务内部矩阵去控制，能不能也实现元老账号也能这么控制呢？
再放下元老账号的全局矩阵授权图，视图能读、任务能读能发布。
原来是并没有在具体任务再额外配置元老账号的权限的，我就想，如果配了，让任务不可读，是否能生效。答案是全局矩阵的策略凌驾于任务矩阵之上，不起效！
再仔细看看有个下拉框，这个就是解题关键了：Inheritance Strategy
可以控制这个任务对元老账号不可见：
从默认的“Inherit permissions from parent ACL”改成这种 “Do not Inherit permissions from parent ACL”
意思就是这个任务，不继承全局安全矩阵策略，如果不单独把这个测试元老账号配置上去，他是完全无法看到这个任务的。
有了这个回收权限和授权都很简单了，平时默认将这个元老账号配置上去，他只有可读权限，如果想给发布权限，就勾选一下“Build”，回收就直接去掉就好啦。
标签：Based,账号,项目,矩阵,Role,授权,Stategy,jenkins,权限 来源： https://www.cnblogs.com/windysai/p/16652353.html