不能不说的秘密：不为人知的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权限修改。

　　用户在第一次登录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中手动将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 V3、Cobit5、C-STAR、TOGAF9.1（鉴定级）等管理认证。

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