jenkins项目矩阵授权和Role-Based Stategy 　　昨晚失眠，顺便想想未解决的问题。通常付出过心血去研究但没有好的结果，心里就会特别纠结，交上去的工作日志也会感觉有点愧疚，写了个600多字阐明测试研究成果：两者原理，授权配置，策略转换风险，诸如此类吧。。。 　　昨晚确实有想到一些思路，今早测试，能行 ^___^ 　　先讲下需求~~~ 一、需求引入 　　某项目A生产系统在9月1日正式上线，未上线前，有个测试元老的jenkins账号（服务了很多年今年6月离职，我挺喜欢他也不舍得他）转交给了新同事，该账号拥有所有jenkins任务（项目A、B、C等等）的发布权限，配置上只需要利用全局项目矩阵授权策略； 　　另一个开发使用的jenkins账号，只给了A项目各个环境的发布权限。配置上不仅要利用全局项目矩阵策略，还要针对A项目下所有任务的项目安全矩阵（A项目各个环境：正式、体验、内测，加起来20多个，也就是20多个都要配）
  （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”，回收就直接去掉就好啦。