0%

[Rancher 系列文] - 使用者登入管理 與 RKE Template 管理

前篇文章透過 rke / helm 成功的搭建了一個 Rancher 服務,並且於第一次登入時按照系統要求創建了一組給 admin 使用的密碼,並且使用該 admin 的帳號觀察到了第一組創建被 Rancher 管理的 Kubernetes 叢集。

複習: 該 K8s 叢集並不是 Rancher 創造的,而是我們事先透過 rke 創造用來部署 Rancher 服務的 k8s 叢集。

對於 IT 管理人員來說,看到一個新的服務通常腦中會閃過的就是該服務的使用者管理權限該怎麼處理? 最直觀也簡單的方式就是透過該服務創建眾多的本地使用者,每個使用者給予不同的權限與帳號密碼。但是這種使用方式實務上會有太多問題

  1. 團隊內員工通常不喜歡每一個服務都有獨立的密碼,最好能夠用一套密碼去存取公司內所有服務
  2. 員工數量過多時,通常團隊也很懶得幫每個員工都獨立創造一份帳號密碼,更常發生的事情是一套帳號密碼多人共同使用。
  3. 多人共同使用的問題就是會喪失了稽核性,沒有辦法知道是誰於什麼時間點進行什麼操作,未來要除錯與找問題時非常困難
  4. 如果權限還想要用群組來管理時,整個要處理的事情就變得又多又複雜
  5. 由於帳號密碼都是服務本地管理,這意味團隊內的帳號密碼是分散式的架構,因此有人想要改密碼就需要到所有系統去改密碼,這部分也是非常不人性化,特別如果員工離職時,要是有服務忘了刪除可能會造成離職員工還有能力去存取公司服務。

因此大部分的 IT 都不喜歡使用本地帳號,更喜歡使用混合模式來達到靈活的權限管理。

  1. 服務想辦法整合外部的帳號密碼系統,常見的如 Windows AD, LDAP, GSuite, SMAL, OpenID, Crowd 等。
  2. 每個服務都維持一個本地使用者,該使用者是管理員的身份,作為一個緊急備案,當外部帳號密碼系統出問題導致不能使用時,就必須要用本地使用者來存取。

混合模式的架構下,所有員工的帳號與密碼都採用集中式管理,任何第三方服務都要與該帳號系統整合,因此

  1. 員工只需要維護一套帳號密碼即可登入團隊內所有服務,如果員工需要改密碼,也只需要改一個地方即可
  2. IT 人員可以統一管理群組,每個第三方服務針對群組去進行權限控管即可。
  3. 這種架構下不會有共享帳號密碼的問題,每個使用者登入任何系統都會有相關的日誌,未來除錯也方便

因此本篇文章就來探討 Rancher 提供何種使用者登入與權限控管,系統管理員架設維護時可以如何友善的去設定 Rancher

Authorization 授權

Rancher 的世界中將權限分成三大塊,由大到小分別是

  1. Global Permission
  2. Cluster Role
  3. Project Role

其中 Cluster/Project 這個概念要到後面章節探討如何用 Rancher 去架設與管理 Kubernetes 叢集時才會提到,因此這邊先專注於第一項,也就是 Global Permission。

Global Permission 代表的是 Rancher 服務本身的權限,本身跟任何 Kubernetes 叢集則是沒有關係。
Rancher 本身採用 RBAC (Role-Based Access Control) 的概念來控制使用者的權限,每個使用者會依據其使用者名稱或是所屬的群組被對應到不同Role。

Global Permission 預設提供多種身份,每個身份都有不同的權限,以下圖來看(Security->Roles)

圖中是預設的不同 Role,每個 Role 都有各自的權限,同時還可以去設定說當一個新的外部使用者登入時,應該要賦予何種 Role
權限部分是採取疊加狀態的,因此設計 Role 的時候都是以 “該 Role 可以針對什麼 API 執行什麼指令”,沒有描述到的就預設當作不允許。
因此 Role 是可以互相疊加來達到更為彈性的狀態,當然預設 Role 也可以有多個。

註: 本圖片並不是最原始的 Rancher 設定,預設狀態有被我修改過,請以自己的環境為主。

Role 這麼多種對於初次接觸 Kubernetes 與 Rancher 的管理員來說實在太複雜與太困難,因此 Rancher 又針對這些 Role 提供了四種好記的名稱,任何使用者與群組都可以基於這四種 Role 為基礎去添加不同的 Role 來達到靈活權限。

這四種好記的 Role 分別為

  1. Administration
    超級管理員,基本上什麼都可以操作,第一次登入時所使用的 admin 帳號就屬於這個權限

  2. Restricted Admin
    能力近乎於超級管理員,唯一不能管理的就是 Rancher 本身所在的 kubernetes 叢集,也就是前篇文章看到的 local 叢集。

  3. Standard User: 可以透過 Rancher 創建 Kubernetes 叢集 並且使用的使用者,大部分情況下可以讓非管理員角色獲得這個權限,不過因為創建過多的 Kubernetes 叢集有可能會造成成本提高,所以賦予權限時也要注意到底什麼樣的人可以擁有創造 kubernetes 叢集的權限。

  4. User-Base: 基本上就是一個 read-only 的使用者,同時因為本身權限很低,能夠看到的資訊非常少,更精準的來說就是一個只能登入的使用者。

Authentication 認證

前述探討如何分配權限,接下來要探討的就是要如何幫使用者進行帳號密碼的驗證,這部分 Rancher 除了本地使用者之外也支援了各式各樣的第三方服務,譬如

  1. Microsoft Active Directory
  2. GitHub
  3. Microsoft Azure AD
  4. FreeIPA
  5. OpenLDAP
  6. Microsoft AD FS
  7. PingIdentity
  8. Keycloak
  9. Okta
  10. Google OAuth
  11. Shibboleth

Rancher v2.6 的其中一個目標就是支援基於 OIDC 的 Keycloak ,因此如果團隊使用的是基於 OIDC 的 Keycloak 服務,讀者不仿可以期待一下 v2.6 的新功能。

使用者可以於 security->authentication 頁面看到如下的設定頁面

官方網站中有針對上述每個類別都提供一份詳細的教學文件,要注意的是因為 Rancher 版本過多,所以網頁本身的內容有可能你會找到的是舊的版本,因此閱讀網頁時請確保你當前看到的版本設定方式與你使用的版本一致。

預設情況下,管理者只能針對一個外部的服務進行認證轉移,不過這只是因為 UI 本身的設定與操作限制,如果今天想要導入多套機制的話是可以從 Rancher API 方面去進行設定,對於這功能有需求的可以參考這個 Github Issue Feature Request - enabling multiple authentication methods simultaneously #24323

實戰演練

上述探討完了關於 Rancher 基本的權限管理機制後,接下來我們就來實際試試看到底用起來的感覺如何。
由於整個機器都是使用 Azure 來架設的,因此第三方服務我就選擇了 Azure AD 作為背後的使用者權限,之後的系列文章也都會基於這個設定去控制不同的使用者權限。

下圖是一個想要達到的設定狀況

Rancher 本身擁有一開始設定的本地使用者之外,還要可以跟 Azure AD 銜接
而 Azure AD 中所有使用者都會分為三個群組,分別是

  1. IT
  2. QA
  3. DEV

我希望 IT 群組的使用者可以獲得 Admin 的權限,也就是所謂整個 Rancher 的管理員。
而 QA/DEV 目前都先暫時給予一個 User-Base 的權限,也就是只能單純登入然後實際上什麼都不能做。
這兩個群組必須要等到後面探討如何讓 Rancher 創建叢集時才會再度給予不同的權限,因此本篇文章先專注於 Rancher 與 AD 的整合。

本篇文章不會探討 Azure AD 的使用方式與概念,因此我已經於我的環境中創建了相關的使用者以及相關的群組。

整合方面分成兩大部分處理

  1. Azure AD 與 Rancher 的整合
  2. Rancher 內的 Roles 設定

Azure AD 的部分可以參考官方教學,裡面有非常詳細的步驟告知要如何去 Azure 內設定,這邊要特別注意就是千萬不要看錯版本,以及最後填寫 Azure Endpoints 資訊時版本不要寫錯。

下圖是 Rancher 內的設定,其中 Endpoints 部分要特別小心

  1. Graph 要使用 https://graph.windows.net/ 而不是使用 Azure UI 內顯示的 https://graph.microsoft.com
  2. Token/Authorization 這兩個要注意使用的是 OAUTH 2.0 (V1) 而不是 V2

下圖是 Azure 方面的設定,所以使用時要使用 V1 的節點而不是 V2,否則整合時候會遇到各種 invalid version 的 internal error.

當這一切整合完畢後重新登入到 Rancher 的畫面,應該要可以看到如下圖的畫面

畫面中告知 Rancher 的登入這時候分成兩種方式,分別是透過 Azure AD 以及使用本地使用者登入。

權限控制

當與 Azure AD 整合完畢後,首先要先透過本地使用者進行權限設定,因為本地使用者本身也是 Admin 的關係,因此可以輕鬆地去修改 Rancher。

如同前面所提,希望整體權限可以是

  1. IT 群組的人為超級使用者
  2. DEV/QA 群組的人為只能登入的使用者 (User-Base)。

同時這邊也要注意,因為 Rancher 的使用者與群組兩個權限是可以分別設定且疊加的,因此設定的時候必須要這樣執行

  1. 將所有第一次登入的外部使用者的預設使用者都改為 (User-Base)
  2. 撰寫群組的相關規則,針對 IT/DEV/QA 進行處理。

預設情況下, Rancher 會讓所有第一次登入的使用者都給予 Standard-User 的權限,也就是能夠創建 k8s 叢集,這部分與我們的需求不同。

所以第一步驟,移動到 security->roles 裡面去修改預設使用者身份,取消 User 並且增加 User-Base

第二步驟則是移動到 security-groups 內去針對不同 Group 進行設定

針對 IT 群組,給予 Administrator 的權限

針對 Dev 群組給予 User-Base 的權限

最後看起來會如下

到這邊為止,我們做了兩件事情

  1. 所有新登入的使用者都會被賦予 User-Base 的權限
  2. 當使用者登入時,會針對其群組添加不同權限
    如果是 IT,則會添加 Administrator 的權限,因此 IT 群組內的人就會擁有 User-Base + Administrator 的權限
    如果是 DEV/QA 的群組,則會添加 Base-User 的權限,因此該群組內的人就會擁有 User-Base + User-Base 的權限,基本上還是 User-Base。

設定完畢後就可以到登入頁面使用事先創立好的使用者來登入。

當使用 Dev 群組的使用者登入時,沒有辦法看到任何 Cluster

相反的如果使用 IT 群組的使用者登入時,則因為屬於 Administrator 的權限,因此可以看到系統上的 RKE 叢集。

前面範例探討了基本權限控管的概念並且展示了使用 Azure AD 後的使用範例,一旦瞭解基礎知識後,接下來就是好好研究 Rancher 內有哪些功能會使用到,哪些不會,針對這部分權限去進行設定,如果系統預設的 Role 覺得不夠好用時,可以自行創立不同的 Roles 來符合自己的需求,並且使用使用者與群組的概念來達到靈活的設定。

當今天透過認證與RBAC等功能完成權限控管後,下一個部分要探討的就是團隊的運作流程。
Rancher 作為一個 Kubernetes 管理平台,最大的一個特色就是能夠輕鬆地於各種架構下去安裝一個 Kubernetes 叢集並且管理它,
雖然到現在為止我們還沒有正式的示範如何創建叢集,但是可以先由下圖看一下大概 Rancher 支援哪些不同類型的架構

圖中分成四種不同類型,這四種類型又可以分成兩大類

  1. 已經存在的 Kubernetes 叢集,請 Rancher 幫忙管理。
  2. 請 Rancher 幫忙創建一個全新的 Kubernetes 叢集並且順便管理。

圖中第一個類型就屬於第一大類,這部分目前整合比較好的有 EKS 與 GKE
這意味者如果你有已經運行的 EKS/GKE 叢集,是有機會讓 Rancher 幫忙管理,讓團隊可以使用一個共同的介面(Rancher)來管理所有的 Kubernetes 叢集。

圖中剩下的(2,3,4)都屬於第二大類,只是這三大類的安裝方式有些不同,分別是

  1. 使用者要事先準備好節點, Rancher 會於這些節點上去創建 RKE 叢集
  2. Rancher 會透過 API 要求服務供應商去動態創建 VM,並且創建 VM 後會自動的建立起 RKE 叢集
  3. 針對部分有提供 Kubernetes 服務的業者, Rancher 也可以直接透過 API 去使用這些 Kubernetes 服務(AKS/EKS/GKE) 並且把 Rancher Agent 安裝進去,接者就可以透過 Rancher 頁面去管理。

這邊點選第三類別的 Azure 作為一個範例來看一下,透過 RKE 安裝 Kubernetes 會有什麼樣的資訊需要填寫

首先上圖看到關於 Cluster Options 下有四大項,這四大項裡面都問題都跟 Kubernetes 叢集,更精準的說是 RKE 有關

首先第一個類別就是 Kubernetes 的基本資訊,包含了

  1. RKE 的版本,版本跟 Kubernetes 版本是一致走向的。
  2. CNI 使用哪套,目前有 Flannel, Calico 以及 Canal。
  3. CNI 需不需要額外設定 MTU
  4. 該環境要不要啟用一些 Cloud Provider 的功能,要的話還要填入一些機密資訊

往下看還有更多選項可以用,譬如該 RKE 創建時,所有用到的 Registry 是否要從一個 Private Registry 來抓取,這功能對某些團隊來說會非常有用,因為部分團隊會希望用到的所有 Container Image 都要有一份備份以免哪天 quay, docker.io 等出現問題導致整個安裝失敗。

因此如果團隊事先將 RKE 用到的 Container Image 都複製一份到自己團隊的 private container registry 的話,就可以打開這個功能讓 Rancher 知道去哪邊抓 Image。

後續則是更多的進階選項,譬如説

  1. RKE 中預設要不要安裝 Nginx 作為 Ingress Controller?
  2. 系統中的 NodePort 用到的範圍多少?
  3. 是否要導入一組預設的 PodSecurityPolicy 來限制叢集內所有Pod的安全性規則
  4. Docker 有沒有特別指定的版本
  5. etcd 要如何備份,要本地備份還是要透過 s3 將 etcd 上傳
  6. 要不要定期透過 CIS 進行安全性相關的掃描?

可以看到上述的設定其實滿多的,如果每次創建一個叢集都要一直輸入一樣的資訊難免會出錯,同時有一些設定 IT 人員會有不同的顧慮與要求。為了讓團隊內的所有 RKE 叢集都可以符合團隊的需求,Rancher 就有提供基於全面系統地 RKE Template.

RKE Template

RKE Template 的概念就是讓系統人員與安全人員針對需求去規範 Kubernetes 的要求,所有使用者都必須要使用這個事先創立的 RKE Template 來創立 RKE 叢集。
透過這個方式有幾個好處

  1. 使用者創立的所有 RKE 叢集都可以符合團隊需求
  2. 使用者使用 Template 去創建 RKE 的話就可以省略那些不確定該怎麼填寫的資訊,簡化整個創造步驟
  3. Template 本身也是一個物件,所以 Rancher 前述提到的權限控管就可以針對 Template 去進行設定,譬如 DEV/QA 人員只能使用已經創建的 Template 來創立 RKE 叢集

以下是一些常見使用 RKE Template 的使用範例

  1. 系統管理人員強迫要求所有新創立的 RKE 叢集都只能使用事先創立好的 RKE Template
  2. 系統管理人員創建不同限制的 RKE Template,針對不同的使用者與群組給予不同的 RKE Template
  3. RKE Template 本身是有版本的概念,所以如果今天公司資安團隊希望調整資安方面的使用,只需要更新 RKE Template 即可。所有使用到的使用者再進行 RKE Template 更新的動作即可

此外 RKE Template 內所有的設定都有一個覆蓋的概念存在,創建該 RKE Template 時可以決定該設定是否能夠被使用者覆蓋,這對於某些很重要的設定來說非常有用。

以下是一個 RKE Template 創建的方式 (Tools->Template 進入)

圖中最上方代表的是該 RKE Template 的名稱與版本,同時每個 RKE Template 有很多個版本,更新的時候可以選擇當前版本是否要作為當前 Template 的預設版本。

中間部分則是到底誰可以使用這個 RKE Template,裡面可以針對使用者與群組去設定身份總共分成兩個身份,分別是 User 以及 Owner。

  1. Owner: 符合這個身份的使用者可以執行 更新/刪除/分享 這些關於 RKE Template 的設定,概念來說就是這個 RKE Template 的擁有者。
  2. User: 簡單來說就是使用這個 RKE Template 的人,使用者再創建 RKE 叢集的時候可以從這些 Template 中去選擇想要使用的 Template。

最下面的部分跟前述探討安裝 RKE 要使用的權限都差不多,唯一要注意的是每個選項旁邊都有一個 “Allow user override?” 的選項,只要該選項沒有打開,那使用者(User)使用時就不能覆蓋這些設定。

實驗

接下來針對 RKE Template 進行一個實驗,該實驗想到達到以下目的。

  1. IT 管理員創建一個 RKE Template,並且設定 DEV 群組的使用者可以使用
  2. DEV 群組的使用者可以創建 Cluster,但是被強迫只能使用 RKE Template 創造,並不是自己填寫任何資訊。

為了達到這個目的,我們有三個步驟要做,分別是

  1. 透過 Rancher 的設定,強迫所有創建 RKE 叢集一定要使用 RKE Template,不得自行填寫資訊。
  2. 創造一個 RKE Template,並且設定 DEV 群組的人是使用者,同時該 RKE Template 內讓 Kubernetes 版本是一個可以被使用者覆蓋的設定。
  3. 登入 DEV 使用者嘗試創造 RKE 叢集,看看上述設定是否可以達到我們的需求。

首先到首頁上方的 Setting,進去後搜尋 template-enforcement 就會找到類似下列這張圖片的樣子

預設狀況下,該設定是 False,透過旁邊的選項把它改成 True,該選項一打開後,所有新的 RKE 叢集都只能透過 RKE Template 來創建。

接者用 IT 人員登入作為一個系統管理員,創建一個如下的 RKE Template

中間部分表示任何屬於 DEV 群組的人都可以使用這個 RKE Template,同時該 RKE Template 允許使用者去修改 Kubernetes 版本,其餘部分都採用 RKE Template 的設定。

最後用 DEV 的身份登入 Rancher 並且嘗試創造一個 RKE 叢集。
從下述畫面可以觀察到一些變化

  1. RKE Template 相關選項 “Use an existing RKE Template and revision” 被強迫打勾,這意味使用者一定要使用 RKE Template
  2. 選擇了前述創造的 RKE Template 後就可以看到之前創造好的設定
  3. 只有 Kubernetes 的版本是可以調整的,其餘部分如 CNI 等都是不能選擇的。

註: 當透過 RKE Template 賦予權限給予 DEV 群組後, 群組那邊的設定會被修改,這時候的 DEV 群組會被自動加上 “Creating new Clusters” 這個權限,範例如下

透過上述的範例操作成功地達到預期目標的設定,讓團隊內所有需要創建 RKE 叢集的使用者都必須要使用事先創造好的 RKE Template 來確保所有叢集都可以符合團隊內的需求。

個人資訊

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程,歡迎有興趣的人參考並分享,裡面有我從底層到實戰中對於 Kubernetes 的各種想法

詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

另外,歡迎按讚加入我個人的粉絲專頁,裡面會定期分享各式各樣的文章,有的是翻譯文章,也有部分是原創文章,主要會聚焦於 CNCF 領域
https://www.facebook.com/technologynoteniu

如果有使用 Telegram 的也可以訂閱下列頻道來,裡面我會定期推播通知各類文章
https://t.me/technologynote

你的捐款將給予我文章成長的動力

Welcome to my other publishing channels