如何理解Kubernetes認證和受權

當設置產品Kubernetes集羣的時候，認證和受權是兩個很重要的基本需求。在這篇文章中，讓咱們來瀏覽一些細節，這些細節能夠幫助Kubernetes環境作好方案。

好比說，你如今已經引起了經過輸入yaml文件到kubectl（kubectl create－f pod.yaml）建立POD的命令。這個命令被髮送到有安全保障的api－server端口（http://），而後身份驗證流就開始生效了。注意，若是你正在爲api－server使用不安全的端口（http://），那麼驗證就沒法應用。（http://）理想狀況下生產環境設置中應該避免不安全端口（http://）。

如下是這篇文章中會提到的在Kubernetes中可以使用的驗證途徑。

客戶證書驗證

爲了使用這個方案，api－server須要用－client－ca－file＝<PATH_TO_CA_CERTIFICATE_FILE>選項來開啓。

CA_CERTIFICATE_FILE確定包括一個或者多個認證中心，能夠被用來驗證呈現給api－server的客戶端證書。客戶端證書的／CN將做爲用戶名。

基於令牌的身份驗證

爲了使用這個方案，api－server須要用－token－auth－file＝<PATH_TO_TOKEN_FILE>選項來開啓。TOKEN_FILE是個csv文件，每一個用戶入口都有下列格式：token，user，userid，group。

Group的名字是隨意的。

令牌文件的例子：

生成tokens的一個很是簡單的方法就是運行如下命令：

基於令牌的身份驗證面臨的挑戰就是，令牌是無期限的，並且對令牌清單作任何的修改都須要從新啓動api－server。

基本認證

爲了使用這個方案，api－server須要使用－basic－auth－file＝<PATH_TO_HTTP_AUTH>選項來開啓。HTTP_AUTH_FILE是個csv文件，每一個用戶入口都有下列格式：password，user name，userid。目前，對AUTH_FILE的任意修都須要從新啓動api－server。

Open ID

Open ID支持也是可用的，可是還在試驗階段。

Keystone

Keystone支持也是可用的，可是還在試驗階段。若是你想要將keystone跟LDAP或者動態目錄服務整合到一塊兒，那麼就要使用keystone認證方法。爲了使用這個方案，api－server須要用－experimental－keystone－url＝<KEYSTONE_URL>選項來開啓服務。

驗證成功以後，下一步就是找出對於驗證用戶來講，哪些操做是容許的。目前來說，Kubernetes支持4種驗證策略方案。api－server須要使用－authorization－mode＝<AUTHORIZATION_POLICY_NAME>選項來開啓。

始終否定

這個策略否定全部的請求。

始終容許

這個策略容許全部的請求。

基於屬性的訪問控制

ABAC容許靈活的用戶特定受權策略。當使用－authorization－policy－file＝<PATH_TO_ABAC_POLICY_FILE>選項開啓api－sever的時候，ABAC的策略文件須要指定。目前，對策略文件有任何的修改都須要重啓api－server。

ABAC策略文件樣本以下所示：

在以上例子中，策略文件中的每一行都是JSON對象，且指定一個策略。這是從Kubernetes文檔頁面上對策略對象的簡要描述。

版本控制特性——容許多版本和策略的轉換格式。

api版本，字符串類型：有效值就是「abac.authorization.kubernetes.io/v1beta1」。

kind，字符串類型：有效值是「policy」。

規格屬性——是一個用如下屬性的映射：

面向對象匹配屬性：

用戶，字符串：用戶字符串不是從－token－auth－file，就是從證書文件的普通名字（CN）而來。若是你指定用戶，那麼它就確定跟通過身份驗證的用戶匹配。＊跟全部請求都匹配。

group，字符串：若是你指定group，那麼它確定跟groups中通過身份驗證的用戶相匹配。＊跟全部請求都匹配。

資源匹配屬性

apiGroup，字符串類型：API group，好比拓展版本。＊跟全部APIgroup相匹配。

命名空間，字符串類型：命名空間字符串。＊跟全部的資源請求相匹配。

資源，字符串類型：資源，好比pods。＊匹配全部的資源請求。

非資源匹配屬性：

nonResourcePath，字符串類型：跟全部的非資源請求路徑相匹配（好比／version，／apis）。＊跟匹配全部非資源請求。／foo／＊跟／foo／，以及它的子路徑。

只讀，布爾型：當爲真，也就意味着策略只應用於獲取，列出和監測操做。

Webhook

調出一個外部RESTful受權服務。

身份驗證和受權機制的選擇取決於你的要求。然而在個人經驗看來，我發現基於證書的身份驗證方法，基於身份驗證方法的keystone（LDAP），基於身份驗證策略的ABAC，這三種方法的靈活結合提供了所需的功能，來培養Kubernetes環境。

想要了解更多關於認證和受權的信息，建議瀏覽一下兩個連接：

認證：http://kubernetes.io/docs/admin/authentication/

受權：http://kubernetes.io/docs/admin/authorization

 

 

原文連接：http://cloudgeekz.com/1045/kubernetes-authentication-and-authorization.html#rd?sukey=3997c0719f1515203c1d484623e7ce856d8c5abebd3e3bf44f7761a8579fb1f1c4bb5e509f603c1481f70266e9e3071a

(轉載請先聯繫咱們，尊重知識產權人人有責：）