詳解K8S與Rancher 2.0內的身份認證與授權
在Rancher 2.0中，我們重點關註的一個領域就是身份認證和授權。在Kubernetes強大的基礎功能之外，Rancher 2.0格外專註於簡易性和易用性
在深入討論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。
詳解K8S與Rancher 2.0內的身份認證與授權