怎么分析K8S與Rancher 2.0內的身份認證與授權

這篇文章將為大家詳細講解有關怎么分析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能夠給組織、管理員和用戶帶來哪些好處。

身份認證

想要理解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模板。然后，集群所有者可以將默認策略分配給集群，并在每個項目基礎上管理例外情況。換句話說，集群所有者可以說：“除了少數特殊項目外，所有項目都有一個限制策略，阻止他們部署特權容器。”此功能可用于安全的多租戶集群。

關于怎么分析K8S與Rancher 2.0內的身份認證與授權就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。