不能不說的祕密：鮮爲人知的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等技術認證