Jenkins-專案權限管理

發表於 更新於 分類於 閱讀次數： Disqus：

jenkins 的專案權限管理練習，之所以會弄這個是因為專案越來越多的話，針對組織內的使用者及專案之間的權限管理，如果還是一個個的設定，不僅容易出錯，也難以整體的確認當前分配的權限概況。

Intro

專案如果採用的是Matrix Authorization Strategy這個 plugin 所提供的專案型矩陣授權策略的話，應該也很納悶 Role 怎麼設定，據我找到的這篇文章Jenkins 权限管理之 Matrix Authorization Strategy來看的話，說是要靠 LDAP 或是 Active Directory 來做，這就牽涉到我不熟悉的網管、主機、域名等等的設定，坦白說這東西對我就是天書。我不可能為了吃一碗麵還去研究要怎麼鑽木取火、把麵團發酵吧。

REF:How to create and add users to a group in Jenkins for authentication?

在該文章得到另外一個關鍵字：Role-based Authorization Strategy，於是就來研究一下怎麼設定這個 plugin

Role-based Authorization Strategy

在Role-based Authorization Strategy的介紹網頁中可以看到基本的用法，大致上的流程就是:安裝->啟用->設定角色群組->設定使用者角色對應

安裝並啟用

安裝套件這個沒有什麼好說的，啟用也很簡單，不外乎就是到管理jenkins->設定全域安全性這邊將授權的下拉選單，從原先的專案型矩陣授權改為Role-Based Strategy

值得一提的是，當你的授權策略改變的話，原先在各個專案的矩陣授權設定，就會一併隱藏起來，若未來調整回來專案型矩陣授權的話，這些被隱藏的授權設定也會回復，至少這個是我測試出來的經驗啦，這樣的話就比較不害怕改壞掉要切回來，然後設定全部消失的窘境，不過因為軟體版本太多，所以最好在調整的時候自己先測試、備份一下原有的專案設定，以免發生了不可挽回的操作，人生跑馬燈就會出現了。

設定角色群組及角色對應

接著到管理jenkins->Security->Manage and Assign Roles

會看到設定角色群組、指派角色的功能

設定有一點點的難懂，但是測試了一下發現的確是挺不錯的，他的設定有三個部分，這邊先關注在Global Roles、Item Roles這兩項就可以了，最後一項Node Rules我還是沒看懂，或許有人可以分享一下？

設定範例

我覺得用範例來解釋會比較好懂，假設我有專案叫做

  1. pipeline_job_1
  2. pipeline_job_2
  3. taskProject

我想要達成的效果是

  1. 沒有特別設定的話，一般的使用者就是只能看到pipeline_job任務，但是不能夠操作
  2. 開發人員(develop)可以執行pipeline_job任務，但是看不到建置設定
  3. 管理人員(manager)針對pipeline_job任務具備所有權限
  4. 所有的人都看不到taskProject，除了 admin

所以整理完需求，描述大概就是像下面這樣

使用者 權限
art 最高管理者(admin)阿，全部打開！！
demouser1 pipeline_job 專案的管理者(manager)
demouser2 pipeline_job 專案的開發人員(develop)
demouser3 什麼都看不到

那麼，我就需要

  1. 針對超級管理者 art 給予全域的超級管理者(admin)權限
  2. 針對管理者 demouser1 作一個管理者(manager)，這個設定對應的專案是 pipeline_job_1 跟 2，且權限都開
  3. 針對開發人員 demouser2 作一個開發人員(develop)，這個設定對應的專案是 pipeline_job_1 跟 2，且權限是 build 跟 read
  4. 最後，針對一般使用者給予全域的什麼都看不到(anyone)的權限

整理一下就是

scope role permission for who? result
全域 admin 全開 art 所有權限
全域 anyone 僅給予整體的 read 沒有特別設定的人 進來介面什麼都沒有
pipeline_job_1 跟 2 Develop 允許 build , read demouser2 可以執行 pipeline_job_1 跟 2
pipeline_job_1 跟 2 Manager 允許該專案所有操作 demouser1 可以執行所有操作

我們先搞定全域的兩個設定，分別是 admin 跟 anyone

接著指派給使用者，因為只有 art 所以只需要指派一個，其他的人就不用特別指派了

透過正則表達式去比對我們要符合的pipeline_job_1、pipeline_job_2這兩個專案，所以 pattern 就是 pipeline_job.*，因為這樣很直觀所以我也沒打算寫得很複雜的 pattern，設定的話就像下面這樣

可以測試一下 pattern match 哪些專案，點一下就可以看到，如果你屬於 regex 之神的話，可以當我沒說

指派使用者，將 demouser1 套用 manager， demouser2 套用 develop

這邊的群組名稱可以命名的更清晰一點，方便管理，例如專案叫做 SuperStar，管理者就可以命名為 SuperStarManager，開發人員就可以命名為 SuperStarDevelop；又或者是你們專案有 SuperStar，TravelToday 都是同一組人，這個團隊叫做 TeamA，那其實也可以把群組名稱命名為 TeamA-Manager 之類的，總之就是讓人一看就知道這個群組是誰，責任範疇在哪裡。千萬不要真的傻傻的明明一個團隊要負責十個專案，結果十個專案還都有各自的 Manager 跟 Develop 或是其他一堆有的沒有的權限，然後搞個每次設定那個清單排到 1920 螢幕寬度都還看不完，那就累人了，不過如果真的硬要好像也是可以拉～（笑）

那麼最後來測試一下每一位使用者登入後的情況，看看是否如我們預期

art，所有專案功能都開放

demo user 1，可以看到 pipeline_job 專案，可以執行且能夠設定建置

demo user 2，可以看到 pipeline_job 專案，可以執行但是不能夠設定建置

demo user 3，應該是什麼都看不到

補充：切換回『專案型矩陣授權策略』

如果設定之後因故，老闆叫你先還原呢？那就直接把一開始提到的管理jenkins->設定全域安全性這邊將授權的下拉選單，再改回來專案型矩陣授權就好了，以pipeline_job_1為例，我在調整之前有把權限給予好幾個 user，調整回來後，設定也回來了

當然，這個步驟再次強調，希望還是要在你自己的環境作一下簡單的 POC 測試，但是如果切回來後還想要切過去Role-based，那麼剛剛設定的就會全部清空，需要全部再重新建立了；雖說是全部重新建立，但其實因為設定也就在兩個頁面的地方，其實如果有做好備份、截圖，甚至用 EXCEL 記錄好有哪些權限設定、群組，其實設定也不繁瑣。

結論

作為一個老牌的軟體，jenkins 是真的很多工具可以用，出問題想找資料也很多，這也是我喜歡 jenkins 的原因，好用的東西功能自然複雜，設定自然就困難，瞭解概念再去處理，自然事半功倍。這也是我整理這篇文章的原因，叫我看官方那一串我真的會看半天還是看不懂。自己 RUN 過一次記錄一下，以後我肯定還會碰上這個問題忘記怎麼設定的。也算救救未來的自己了