Kubernetes叢集安全-API Server認證及授權

Kubernetes叢集安全-API Server認證及授權

目錄

一 Kubernetes叢集安全

1.1 安全機制

二 API Server認證管理

2.1 認證安全

2.2 HTTPS認證原理

2.3 HTTP Token認證原理

2.4 HTTP Base認證原理

三 API Server授權管理

3.1 授權管理概述

四 ABAC授權模式

4.1 ABAC授權政策

4.2 ABAC授權算法

4.3 使用kubectl授權機制

4.4 常見ABAC示例

五 RBAC授權模式

回到頂部

Kubernetes通過一系列機制來實作叢集的安全控制，其中包括API Server的認證授權、準入控制機制及保護敏感資訊的Secret機制等。叢集的安全性主要有如下目标：

保證容器與其所在主控端的隔離。

限制容器給基礎設施或其他容器帶來的幹擾。

最小權限原則—合理限制所有元件的權限， 確定元件隻執行它被授權的行為， 通過限制單個元件的能力來限制它的權限範圍。

明确元件間邊界的劃分。

劃分普通使用者和管理者的角色。

在必要時允許将管理者權限賦給普通使用者。

允許擁有Secret資料（Keys、 Certs、 Passwords） 的應用在叢集中運作。

Kubernetes叢集中所有資源的通路和變更都是通過Kubernetes API Server的RESTAPI來實作的，是以叢集安全的關鍵點就在于如何識别并認證用戶端身份（Authentication），以及随後通路權限的授權（Authorization）環節。

Kubernetes叢集提供了3種級别的用戶端身份認證方式。

HTTPS證書認證：此方式最嚴格，基于CA根證書簽名的雙向數字證書認證方式。

HTTP Token認證：通過一個Token來識别合法使用者。

HTTP Base認證：通過使用者名+密碼的方式認證。

此方式需要有一個CA憑證，CA是PKI系統中通信雙方都信任的實體，被稱為可信第三方（TrustedThirdParty，TTP）。CA作為可信第三方的重要條件之一就是CA的行為具有非否認性。作為第三方而不是簡單的上級，就必須能讓信任者有追究自己責任的能力。

CA通過證書證明他人的公鑰資訊，證書上有CA的簽名。使用者如果因為信任證書而有了損失，則證書可以作為有效的證據用于追究CA的法律責任。正是因為CA承擔責任的承諾，是以CA也被稱為可信第三方。

在很多情況下，CA與使用者是互相獨立的實體，CA作為服務提供方，有可能因為服務品質問題（例如，釋出的公鑰資料有錯誤）而給使用者帶來損失。在證書中綁定了公鑰資料和相應私鑰擁有者的身份資訊，并帶有CA的數字簽名；在證書中也包含了CA的名稱，以便于依賴方找到CA的公鑰，驗證證書上的數字簽名。

CA認證涉及諸多概念，比如根證書、自簽名證書、密鑰、私鑰、加密算法及HTTPS等。

如下大緻為SSL協定的流程，在Kubernetes CA中認證大概包含下面幾個步驟：

HTTPS通信雙方的伺服器端向CA機構申請證書，CA機構是可信的第三方機構，它可以是一個公認的權威企業，也可以是企業自身。企業内部系統一般都用企業自身的認證系統。CA機構下發根證書、服務端證書及私鑰給申請者。

HTTPS通信雙方的用戶端向CA機構申請證書，CA機構下發根證書、用戶端證書及私鑰給申請者。

用戶端向伺服器端發起請求，服務端下發服務端證書給用戶端。用戶端接收到證書後，通過私鑰解密證書，并利用伺服器端證書中的公鑰認證證書資訊比較證書裡的消息，例如，比較域名和公鑰與伺服器剛剛發送的相關消息是否一緻，如果一緻，則用戶端認可這個伺服器的合法身份。

用戶端發送用戶端證書給伺服器端，服務端在接收到證書後，通過私鑰解密證書，獲得用戶端證書公鑰，并用該公鑰認證證書資訊，确認用戶端是否合法。

用戶端通過随機密鑰加密資訊，并發送加密後的資訊給服務端。在伺服器端和用戶端協商好加密方案後，用戶端會産生一個随機的密鑰，用戶端通過協商好的加密方案加密該随機密鑰，并發送該随機密鑰到伺服器端。伺服器端接收這個密鑰後，雙方通信的所有内容都通過該随機密鑰加密。

上述是雙向認證SSL協定的具體通信過程，這種情況要求伺服器和使用者雙方都有證書。單向認證SSL協定則不需要用戶端擁有CA憑證，對于上面的步驟，隻需将伺服器端驗證客戶證書的過程去掉，之後協商對稱密碼方案和對稱通話密鑰時，伺服器發送給客戶的密碼沒被加密即可。

HTTP Token的認證是用一個很長的特殊編碼方式的并且難以被模仿的字元串—Token來表明客戶身份的一種方式。在通常情況下，Token是一個很複雜的字元串，比如我們用私鑰簽名一個字元串後的資料就可以被當作一個Token。此外，每個Token對應一個使用者名，存儲在API Server能通路的一個檔案中。當用戶端發起API調用請求時，需要在HTTP Header裡放入Token，這樣一來，API Server就能識别合法使用者和非法使用者了。

通常，HTTP是無狀态的，浏覽器和Web伺服器之間可以通過Cookie來進行身份識别。桌面應用程式（比如新浪桌面用戶端、SkyDrive用戶端、指令行程式）一般不會使用Cookie，若需要與Web伺服器之間通信并且進行認證。則需要使用HTTP Base認證，這種認證方式是把“使用者名+冒号+密碼”用BASE64算法進行編碼後的字元串放在HTTP Request中的Header Authorization域裡發送給服務端，服務端在收到後進行解碼，擷取使用者名及密碼，然後進行使用者身份鑒權。

當用戶端發起API Server調用時，API Server内部要先進行使用者認證，然後執行使用者授權流程，即通過授權政策來決定一個API調用是否合法。對合法使用者進行授權并且随後在使用者通路時進行鑒權，是權限與安全系統的重要一環。

授權就是授予不同的使用者不同的通路權限。

API Server目前支援以下幾種授權政策（通過API Server的啟動參數“--authorization-mode”設定）：

AlwaysDeny：表示拒絕所有請求，一般用于測試。

AlwaysAllow：允許接收所有請求，如果叢集不需要授權流程，則可以采用該政策，這也是Kubernetes的預設配置。

ABAC（Attribute-BasedAccessControl）：基于屬性的通路控制，表示使用使用者配置的授權規則對使用者請求進行比對和控制。

Webhook：通過調用外部REST服務對使用者進行授權。

RBAC：Role-BasedAccessControl，基于角色的通路控制。

Node：是一種專用模式，用于對kubelet發出的請求進行通路控制。

API Server在接收到請求後，會讀取該請求中的資料，生成一個通路政策對象，如果在該請求中不帶某些屬性（如Namespace），則這些屬性的值将根據屬性類型的不同，設定不同的預設值（例如，為字元串類型的屬性設定一個空字元串；為布爾類型的屬性設定false；為數值類型的屬性設定0）。然後将這個通路政策對象和授權政策檔案中的所有通路政策對象逐條比對，如果至少有一個政策對象被比對，則該請求被鑒權通過，否則終止API調用流程，并傳回用戶端的錯誤調用碼。

在API Server啟用ABAC模式時，需要指定授權政策檔案的路徑和名稱（--authorization-policy-file=SOME_FILENAME），授權政策檔案裡的每一行都以一個Map類型的JSON對象進行設定，這被稱為“通路政策對象”。通過設定通路政策對象中的apiVersion、kind、spec屬性來确定具體的授權政策。

其中，apiVersion目前版本為abac.authorization.kubernetes.io/v1beta1；kind被設定為Policy；spec指詳細的政策設定，包括主題屬性、資源屬性、非資源屬性這三個字段。

主體屬性

user（使用者名）：字元串類型，該字元串類型的使用者名來源于Token檔案（--token-auth-file參數設定的檔案）或基本認證檔案中使用者名稱段的值。

group（使用者組）：在被設定為“system:authenticated”時表示比對所有已認證的請求，在被設定為“system:unauthenticated”時表示比對所有未認證的請求。

資源屬性

API Group（API組）：字元串類型，表明比對哪些API Group，例如extensions或*（表示比對所有API Group）。

namespace（命名空間）：字元串類型，表明該政策允許通路某個Namespace的資源，例如kube-system或*（表示比對所有Namespace）。

resource（資源）：字元串類型，API資源對象，例如pods或*（表示比對所有資源對象）。

非資源屬性

nonResourcePath（非資源對象類路徑）：非資源對象類的URL路徑，例如/version或/apis，表示比對所有非資源對象類的請求路徑，也可以設定為子路徑，/foo/表示比對所有/foo路徑下的所有子路徑。

readonly（隻讀辨別）：布爾類型，當它的值為true時，表明僅允許GET請求通過。

API Server進行ABAC授權的算法為：在API Server收到請求之後，首先識别出請求攜帶的政策對象的屬性，然後根據在政策檔案中定義的政策對這些屬性進行逐條比對，以判定是否允許授權。如果有至少一條比對成功，那麼這個請求就通過了授權（不過還是可能在後續其他授權校驗中失敗）。

常見的政策配置如下：

要允許所有認證使用者做某件事，可以寫一個政策，将group屬性設定為system:authenticated。

要允許所有未認證使用者做某件事，可以把政策的group屬性設定為system:unauthenticated。

要允許一個使用者做任何事，将政策的API Group、namespace、resource和nonResourcePath屬性設定為“*”即可。

kubectl使用API Server的/api和/apis端點來擷取版本資訊。要驗證kubectlcreate/update指令發送給伺服器的對象，kubectl需要向OpenAPI進行查詢，對應的URL路徑為/openapi/v2。

當使用ABAC授權模式時，下列特殊資源必須顯式地通過nonResourcePath屬性進行設定:

API版本協商過程中的/api、/api/、/apis、和/apis/。

使用kubectlversion指令從伺服器擷取版本時的/version。

create/update操作過程中的/swaggerapi/*。

在使用kubectl操作時，如果需要檢視發送到API Server的HTTP請求，則可以将日志級别設定為8。

更多ABAC參考：《附007.Kubernetes ABAC授權》。

見《附006.Kubernetes RBAC授權》

作者：木二

出處：

http://www.cnblogs.com/itzgr/