不能不说的秘密：鲜为人知的OpenShift Jenkins权限细节

一. 介绍

　　本文将对OpenShift中jenkins的权限进行详细说明。
　　OpenShift中的jenkins使用OpenShift login插件实现了统一的用户登陆，经过在启动jenkins pod时设置环境变量OPENSHIFT_ENABLE_OAUTH=true开启该插件。
　　更多OpenShift jenkins的参数设置，请参考官方说明

二. 用户映射

　　使用OCP用户登陆jenkins，OpenShift login插件会将ocp用户映射为jenkins用户，映射规则为:
ocp_user_name —> ocp_user_name-project_user_role
　　其中jenkins_project_role至少为admin，edit，view中的一个,不然该用户没法登陆jenkins。
　　例如ocp用户tom在jenkins所在的project的role为edit，那么在jenkins中用户名将被映射为tom-edit，jenkins中的赋权要对tom-edit操做。能够在jenkins的用户列表查看，以下图：

注意：能够登陆jenkins的用户必须在jenkins pod所在的project中赋予admin或edit或view的权限。

三. 赋权模型

　　默认状况下，jenkins使用的是安全矩阵受权策略，在jenkins中经过“系统管理-Configure Global Security-受权策略”查看，如图：

　　能够看到默认经过一个二维的矩阵来实现对用户赋权。安全矩阵权限说明可自行百度获取，这里再也不赘述。
　　在这种赋权模型下，OCP中一个有权限的用户第一次登陆jenkins时，会自动完成用户映射和矩阵赋权，OCP三种角色对应jenkins矩阵的权限以下图：

　　经过上面两张图的映射关系能够看出：用户在OCP中赋予role的权限与jenkins权限是保持一致的。
　　例如test1用户在jenkns所在的project中是view权限，则表示对项目中的全部资源对象为只读权限。那么在jenkins中，该用户对全部job也为只读权限。
　　另外，OCP权限到jenkins权限的映射有一个特性，在用户每次登录的时候，会检查权限矩阵中是否有映射用户的条目，只检测条目是否存在，而不关心条目中具体的权限内容。只要在jenkins中把映射用户的权限条目删除，下次用户登陆才会从新自动添加。

四. 权限修改

　　从赋权模型中能够看出，用户权限有用户在OCP中的权限（使用role赋权）和在jenkins中的权限（使用矩阵赋权），这样权限修改就涉及到OCP权限修改和jenkins权限修改。

OCP权限修改

　　用户在第一次登陆jenkins时，已经完成了权限的映射。这时，修改用户在OCP中role，用户下次登陆的时候，须要从新完成用户映射和矩阵赋权。由于用户在ocp中的role发生变化以后，在jenkins中的映射用户名也相应改变了。如上述示例中，dev1在OCP中有edit role，相对应的在jenkins中对全部job有编辑权限，而在OCP中将dev1修改成view role以后，再次登陆jenkins，能够发现dev1已经没有编辑权限了。

　　再看如今的权限矩阵以下图：

　　能够在权限矩阵中新增长了dev1-view的条目，而dev-admin的条目依然存在，可是已经不起做用了，本质缘由是此时dev1用户在jenkins的映射用户已经变为dev1-view了。
　　因为用户登陆只校验条目存在，为了不影响管理员赋权中出现错误，建议在变动用户OCP role的时候将jenkins中多余的条目删除，步骤以下：
1）删除权限矩阵中的无效条目
2）删除无效的用户映射，在jenkins Users页面操做。

jenkins权限修改

　　用户在第一次登陆jenkins时，已经完成了权限的映射。在jenkins的权限矩阵中已经包含了映射用户的条目，这样用户下次登录的时候（只校验条目存在，不校验具体的权限）并不会再次修改权限矩阵。所以咱们能够在用户第一次完成权限映射以后，手动在jenkins中修改用户的权限。
　　例如，在jenkins中手动将dev1-view的条目赋予编辑权限，以下图：

　　dev1用户再次登陆jenkins时，对job已经有了编辑权限。而在OCP中，dev1依然赋予的是view的role。

　　鉴于这种特性，jenkins管理员能够手动在权限矩阵中为特定角色的用户或者组提早设置权限，而不受OCP中role的限制。

五. 用户映射与权限计算规则

　　1）OCP中用户若是有多个role，在jenkins中映射用户只能是一个，并且是按最大的role映射。role按权限大小排序为admin > edit > view。相应的用户权限映射也是以最大的为准。
　　例如用户dev1同时具备admin和view role，那么在jenkins中的映射用户为dev1-admin，映射在权限矩阵中的默认权限为admin，对全部job都有编辑权限。
　　2）安全矩阵的权限是追加的，这说明若是一个用户X在A,B,C三个组中,那么X的权限是联合了用户X,组A,B,C和匿名用户的全部权限。

　　上述介绍的是OCP jenkins默认使用的受权策略，能够看到“安全矩阵受权策略”实现了从ocp权限到jenkins权限的映射，可是安全矩阵的权限是全局的配置，也就是在安全矩阵中配置一个用户为只读权限，那么这个用户对jenkins中全部的job均是只读权限，没法作到基于jenkins job层面的权限控制，下面咱们将进一步介绍“项目矩阵受权策略”，用于实现基于job层面的权限控制。

六. 项目矩阵受权策略

　　这种策略是“安全矩阵受权策略”的扩展，某些特性与安全矩阵很是相似，可是能够基于job层面作独立的权限控制，幸运的是，OCP的用户彻底支持映射到这种权限策略上。
　　这种策略包含了全局权限矩阵和项目权限矩阵两部分，全局权限在jenkins系统管理中配置，项目权限在每一个job中配置。默认全局权限会追加到项目权限中，但也能够在项目权限中阻止全局权限的追加。

6.1 用户映射

　　这种策略下的用户映射规则与“安全矩阵受权策略”彻底一致。

6.2 赋权模型

　　项目矩阵受权策略分为全局权限矩阵和项目权限矩阵两部分：
　　全局权限矩阵在jenkins中经过“系统管理-Configure Global Security-受权策略”查看，以下图：

　　如图所示，二维矩阵与“安全矩阵受权策略”是彻底同样的。
　　项目权限矩阵在每一个job中配置，以下图：

　　项目权限矩阵与全局相比，只包含Credentials，Job，Run，SCM的权限控制，默认全局权限会追加到项目权限中，经过勾选参数“Block inheritance of global authorization matrix”使得不会继承全局权限，这样能够配置job具备比全局权限更严格的访问控制，可是建议最好不要开启。
　　若是不使用该策略的项目权限矩阵的话，与“安全矩阵受权策略”将彻底一致。而项目权限矩阵是在每一个job中由管理员开启的，因此OCP用户的权限映射只会映射到该策略的全局权限矩阵中，且与“安全矩阵受权策略”中的彻底一致。
　　例如test1用户在jenkns所在的project中是view权限，则表示对项目中的全部资源对象为只读权限。那么在jenkins中，该用户在全局权限矩阵中为只读权限，若是job-test1开启项目权限矩阵，且该用户有项目矩阵全部权限，那么最终用户test1仅有对job-test1有读写权限，而对其余job有只读权限。
　　这种策略下，在用户每次登录的时候，会同时检查全局权限矩阵和项目权限矩阵中是否有映射用户的条目，一样只检测条目是否存在，而不关心条目中具体的权限内容。只要在jenkins中把映射用户的全局权限矩阵和项目权限矩阵的条目所有删除，下次用户登陆才会从新自动添加全局权限矩阵的条目。

6.3 使用方法

　　将受权策略由以前的“安全矩阵”切换到“项目矩阵受权策略”以后，默认只有匿名用户，且什么权限都没有。注意，这种状况下，绝对不要直接保存，不然连管理员都没法登陆了。

　　若是全局矩阵为空保存的话，ocp的用户登陆会报以下错误：

　　解决办法有以下两个：
　　1）采用与安全矩阵同样的处理方法，在全局矩阵中加入admin用户（该用户为jenkins初始化生成的用户）为管理员

　　这种方法一般状况下没有问题，下面场景将致使用户没法登陆jenkins。
　　例如一个用户dev2，在ocp中有view role，这样映射到全局权限矩阵为dev2-view对全部项目有只读权限，并启用job-dev2的项目权限矩阵，并赋予dev2-view用户对job有全部权限。此时若是将全局权限矩阵中的dev2-view条目删除，可是项目权限矩阵中依然包含dev2-view的条目，在用户下次登陆的时候并不从新添加全局权限，直接致使用户dev2由于没有overall/read权限而没法登陆jenkins。这也是前面建议不要开启参数“Block inheritance of global authorization matrix”的缘由。
　　2）赋予匿名用户Overall/read权限

　　因为权限是追加的，全部用户都将追加匿名用户的权限，这样就能够保证不管用户在全局权限矩阵中的是否有条目存在，都将有overall/read权限。这种方式的惟一弊端是用户不须要登陆就能够看到jenkins界面，可是没有任何的操做权限，以下图：

　　优先推荐第二种方式，若是很是在乎匿名用户看到jenkins界面，则能够选择第一种方式，可是必定要避免仅删除全局权限矩阵的条目而保留项目权限矩阵。

6.4 权限修改和规则

　　与“安全矩阵受权策略”彻底一致。用户能够在jenkins中修改也能够在ocp中修改，惟一的须要注意的是在“项目矩阵受权策略”下OCP的权限只会映射到全局矩阵策略中，而真正的权限是包含全局和项目两部分的。
　　用户的映射规则和权限计算规则也是彻底同样的，此处再也不赘述。

七. 总结

　　OCP的用户使用用户名和role映射到jenkins中的用户，默认使用“安全矩阵受权策略”，这种方式对jenkins中全部job均生效。能够切换为“项目矩阵受权策略”以实现对单个job实现权限控制。“项目矩阵受权策略”分为全局权限矩阵和项目权限矩阵，OCP中的权限可映射到全局权限矩阵中，而项目权限矩阵须要管理员手动完成配置。
　　

魏新宇

• "大魏分享"运营者、红帽资深解决方案架构师

• 专一开源云计算、容器及自动化运维在金融行业的推广

• 拥有MBA、ITIL V三、Cobit五、C-STAR、TOGAF9.1（鉴定级）等管理认证。

• 拥有红帽RHCE/RHCA、VMware VCP-DCV、VCP-DT、VCP-Network、VCP-Cloud、AIX、HPUX等技术认证