詳解K8S與Rancher 2.0內的身份認證與受權

Rancher 2.0正式版已全面發佈。Rancher 2.0是一個開源的Kubernetes管理平臺，爲企業用戶提供Kubernetes-as-a-Service (Kubernetes即服務)，而且可以實現多Kubernetes集羣的統一納管。這一創造性的統一納管功能將解決生產環境中企業用戶可能面臨的基礎設施不一樣的困境。Rancher 2.0是業界第一個能統一納管來自Google（GKE）、Amazon（EKS）和Azure（AKS）等公有云上託管的Kubernetes服務的平臺。

在Rancher 2.0中，咱們重點關注的一個領域就是身份認證和受權。在Kubernetes強大的基礎功能以外，Rancher 2.0格外專一於簡易性和易用性，它是一個既強大又易於使用的系統。Rancher 2.0讓管理員可以管理多集羣環境，同時還可以幫助用戶快速啓動並運行環境。本文將從身份認證和受權的角度，介紹Rancher可以給組織、管理員和用戶帶來哪些好處。

在深刻討論Rancher能帶來什麼以前，咱們將先在本文前半部分簡要回顧一下Kubernetes身份認證與受權相關的概念。若是想深刻了解這些概念的更多細節，可參考Kubernetes官方的文檔：

https://kubernetes.io/docs/admin/authentication/

https://kubernetes.io/docs/admin/authorization/rbac/

身份認證

想要理解Kubernetes的身份認證以及Rancher如何對這一功能進行拓展增強，那麼就必需要先理解下面這幾個關鍵的概念：身份認證策略、用戶和組，以及用戶模擬。

身份認證策略（Authentication Strategies）

Kubernetes提供了多種身份認證策略，包括：客戶端證書、OpenID Connect令牌、Webhook令牌認證、身份認證代理、服務帳戶令牌等等。每一種策略都有它的優缺點，但最終它們都要負責判斷申請API調用的用戶的身份，這樣Kubernetes RBAC框架才能夠決定是否要受權給申請調用者，讓其執行其請求的操做。

儘管已經有大量可用的策略能解決大多數狀況，但須要注意的是，配置它們須要精確控制Kubernetes控制平臺的配置和部署。像Google這樣的雲服務提供商一般會將其鎖定，防止用戶按照本身的喜愛配置它。而Rancher 2.0解決了這個問題，咱們會在後面討論。

用戶和組（Users and Groups）

Kubernetes有兩種類型的用戶：服務帳戶和普通用戶。其中服務帳戶徹底由Kubernetes管理，而「普通」用戶則徹底不受Kubernetes的管理。事實上，Kubernetes沒有用戶或組的API資源。所以最終，普通用戶和組在用戶綁定中表現爲晦澀的對象，用以作權限的檢查。

用戶模擬（User Impersonation）

Kubernetes中的用戶模擬是一個用戶（或服務帳戶）扮演另外一個用戶的能力。一個subject必須明確地具備「模擬」特權，纔可以執行對其餘用戶的模擬。雖然這可能看起來是一個至關模糊和細微的功能，但它對於Rancher如何實現身份驗證相當重要。

授 權

要理解Kubernetes中的受權以及Rancher如何構建它，還必須理解這些概念：roles（角色）、clusterRoles（集羣角色）、roleBindings（角色綁定）和clusterRoleBindings（集羣角色綁定）。從命名就能看出，這些概念之間很是類似，但適用於不一樣的範圍。

roles是命名空間的一個做用域，這意味着它是在命名空間中建立的，而且只能由該命名空間內的roleBinding引用。roleBinding在用戶、組或者服務帳戶（在Kubernetes中稱爲subject）和命名空間中的role之間建立關聯。它有效地說明了用戶 X在命名空間Z中具備Y角色，或者咱們給一個具體的例子：Sarah可以在「dev」這個命名空間中進行部署的建立、更新和刪除。

clusterRole的樣子和做用方面與role很是類似。惟一的區別是它沒有命名空間。clusterRole是在集羣層面定義的。一樣的，clusterRoleBinding是roleBinding的無命名空間版本。當你建立clusterRoleBinding時，意味着你爲特定的subject賦予了可用於整個集羣、每一個命名空間的權限。

須要注意的是：roleBinding能夠引用role或者clusterRole。不管它引用的role類型是什麼，權限只適用於rolebinding所在的命名空間。

有了對Kubernetes基礎概念的理解，咱們接下來能夠開始討論Rancher是如何使用和加強它們，建立出強大且易於使用的身份認證和受權系統的。

Rancher的身份認證和受權

Rancher 2.0的主要目標之一，是幫助系統管理員運行多個異構的Kubernetes集羣。這些集羣能夠是來自於雲提供商或本地解決方案的任何組合，這就產生了許多有趣的身份認證和受權挑戰。其中咱們肯定並解決的關鍵問題是：

• 如何在不一樣類型的集羣中擁有統一的身份驗證體驗？

• 如何管理跨集羣的用戶和權限？

• 如何啓用「自動服務」方式使用集羣，同時保持適當的控制水平？

• 如何防止用戶在低信任環境中得到對底層基礎設施資源的過多訪問？

每一種挑戰咱們接下來都會討論。

統一認證

爲了實現跨集羣的統一身份認證體驗，咱們將Rancher服務器設計成全部身份驗證的中心點。管理員只需在Rancher中配置一次身份認證工具，它就能夠應用到任何地方。以後，在全部訪問Kubernetes集羣的請求面前，Rancher都至關於一個身份驗證代理。

因爲大多數雲提供商不公開必要的hooks用來插入Kubernetes的各類認證策略，所以Rancher的身份驗證代理位於外部，獨立於集羣而存在。它執行必要的身份認證工做，收集用戶的身份和任何的組，而後經過用戶模擬將請求轉發到適當的集羣，以充當該用戶。正由於認證方法是標準的Kubernetes無記號令牌，所以Rancher的代理能夠無縫地插入kubectl等現有的Kubernetes工具中。

用戶管理

正如以前所說，Kubernetes沒有一等用戶的理念，而Rancher有。用戶能夠由管理員手動建立，也能夠在GitHub等身份認證工具那裏按需建立（Github在頭一次打開時須要用戶登陸）。咱們從Rancher 1.x中吸收了經驗教訓，在默認狀況下，本地身份認證是開啓且始終開啓的。這樣以來，Rancher在默認狀況下是安全的，而且在身份認證工具出現故障時提供了訪問Rancher的備份機制。

建立一個駐留在中央Rancher服務器上的一等用戶資源能夠帶來不少好處。例如，管理員如今能夠查看和操做任何特定用戶對全部集羣的訪問權限。它還使Rancher可以管理特定於每一個用戶的資源，如系統首選項、API令牌和節點模板。最後，它使得管理用戶權限變得更簡單，咱們將在下文討論。

RBAC 受權

在深刻討論受權以前，咱們必須先介紹和討論一個關鍵的Rancher概念：項目。項目是能夠應用於各類策略的命名空間的集合。這些策略（並不是全部的策略都進入了咱們的初始GA版本）包括RBAC、網絡訪問、pod安全性和配額管理。項目「擁有」命名空間，以及爲項目所作的任何RBAC綁定都適用於項目中的全部命名空間。這個關鍵概念容許將集羣有效地分割和組織成更小、更易於管理的塊(chunks)。

Rancher有效地爲用戶提供了三層roles或權限：全局、集羣和項目層級。全局定義了你能夠在單個集羣以外執行的操做。對於大多數人來講，這能夠認爲是將用戶或組的子集標記爲「管理員」，其他部分標記爲「普通」用戶。除了能夠徹底訪問全部集羣外，管理員還能夠執行配置身份驗證提供者和管理用戶等操做。而普通用戶只能訪問他們擁有或已被邀請的集羣或項目。

Rancher RBAC直接創建在Kubernetes RBAC之上（前面討論的role和binding概念）。若是你瞭解Kubernetes的概念，Rancher RBAC就很容易理解。實際上，咱們在Rancher服務器中建立roles和bindings模板，並將它們傳播到適當的集羣。所以，咱們在Rancher API中有如下自定義資源：roleTemplates,clusterRoleTemplateBindings以及projectRoleTemplateBindings。管理員能夠管理roleTemplates和集羣，而項目全部者可使用它們授予對其集羣或項目不一樣程度的訪問權限。

自助服務訪問

Rancher默認支持自助服務訪問模式，幫助組織受權用戶從Kubernetes得到更多信息。普通用戶能夠建立本身的集羣併成爲其全部者。他們是該集羣的管理員，能夠將其餘用戶和組設成集羣成員，授予他們訪問權限。一旦用戶成爲了集羣成員，它就能夠在集羣中建立項目併成爲這些項目的全部者。做爲項目全部者，能夠邀請其餘人稱爲項目成員或全部者。項目成員可以在他們所屬的項目中建立命名空間並部署工做負載。你能夠看到，這個自助服務系統是如何建立的，並讓用戶可以快速且輕鬆地啓動和運行。

而這種方式下，也有常見的問題：「若是我不想讓用戶建立集羣或項目，該怎麼辦？」

這一問題有幾個答案。首先，若是他們不能訪問基礎設施資源（意味着他們沒法建立虛擬機或者沒有組織雲提供商的密鑰），那麼他們沒法建立功能集羣。其次，咱們的RBAC系統是可配置的，這樣管理員能夠在默認狀況下明確地選擇用戶能夠作什麼。最後，用戶能夠直接被添加到項目中，而不須要建立明確的集羣成員。這意味着他們將不能建立新的項目，而只能使用那些他們被明確添加進去的項目。經過這種方式，Rancher使組織可以受權它們的用戶，同時給予管理員他們所須要的控制。

控制基礎設施層級的訪問

許多用例會要求用戶限制他們能夠部署的容器類型以及這些容器容許執行的內容。爲了解決這個問題，Kubernetes搬出了podSecurityPolicies。這是一個很是重要的功能，但它的原始形式卻很難正確使用。關於它是如何工做的，以及他能作什麼，這些討論操出了本文的範圍，但咱們能夠這麼總結它：podSecurityPolicies容許管理員限制能夠部署在集羣中的pod類型。用一個簡單和容易理解的例子來講就是，它能夠防止用戶部署特權容器，這爲許多用例解決了大的安全漏洞。

Rancher不只支持podSecurityPolicies，並且加強了該功能，大大提升了可用性。使用Rancher，管理員能夠在全局定義一組用於全部集羣的podSecurityPolicy模板。而後，集羣全部者能夠將默認策略分配給集羣，並在每一個項目基礎上管理例外狀況。換句話說，集羣全部者能夠說：「除了少數特殊項目外，全部項目都有一個限制策略，阻止他們部署特權容器。」此功能可用於安全的多租戶集羣。

總 結

經過本文，但願你能看到咱們在Rancher 2.0中對身份驗證和受權的關注。全部這一切都創建在Kubernetes基本概念的基礎之上。秉承Rancher一向關注可用性及簡單性的原則，Rancher 2.0對Kubernetes身份認證和受權進行了更多加強和擴展，以建立出更增強大的組合，幫助企業用戶更簡單快捷落地Kubernetes。