Linux教程

jenkins项目矩阵授权和Role-Based Stategy

本文主要是介绍jenkins项目矩阵授权和Role-Based Stategy,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
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”,回收就直接去掉就好啦。

 

这篇关于jenkins项目矩阵授权和Role-Based Stategy的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!