Kubernetes1.5正式發(fā)布修復了很多已知問題，進一步增強federation相關特性、將PetSet改名為StatefulSet、將ScheduledJobs改名為CronJobs、新增了命令kubectl，用于操作federation等，本篇文章為大家分享一下Kubernetes1.5新增特性Kubelet API增加認證和授權能力。

創(chuàng)新互聯公司于2013年成立，先為沈河等服務建站，沈河等地企業(yè)，進行企業(yè)商務咨詢服務。為沈河企業(yè)網站制作PC+手機+微官網三網同步一站式服務解決您的所有建站問題。

背景介紹

在Kubernetes1.5中，對于kubelet新增加了幾個同認證/授權相關的幾個啟動參數，分別是：

認證相關參數：

anonymous-auth參數：是否啟用匿名訪問，可以選擇true或者false，默認是true，表示啟用匿名訪問。

authentication-token-webhook參數：使用tokenreviewAPI來進行令牌認證。

authentication-token-webhook-cache-ttl參數：webhook令牌認證緩存響應時長。

client-ca-file參數：表示使用x509證書認證，如果設置此參數，那么就查找client-ca-file參數設置的認證文件，任何請求只有在認證文件中存在的對應的認證，那么才可以正常訪問。

授權相關參數：

authorization-mode參數：kubelet的授權模式，可以選擇AlwaysAllow或者Webhook，如果設置成Webhook，那么使用SubjectAccessReviewAPI進行授權。

authorization-webhook-cache-authorized-ttl參數：webhook授權時，已經被授權內容的緩存時長。

authorization-webhook-cache-unauthorized-ttl參數：webhook授權時，沒有被授權內容的緩存時長。

認證

默認anonymous-auth參數設置成true，也就是可以進行匿名認證，這時對kubelet API的請求都以匿名方式進行，系統(tǒng)會使用默認匿名用戶和默認用戶組來進行訪問，默認用戶名“system:anonymous”，默認用戶組名“system:unauthenticated”。

可以禁止匿名請求，這時就需要設置kubelet啟動參數：“–anonymous-auth=false”，這時如果請求時未經過認證的，那么會返回“401 Unauthorized”。

可以使用x509證書認證（X.509格式的證書是最通用的一種簽名證書格式）。這時就需要設置kubelet啟動參數：“–client-ca-file”，提供認證文件，通過認證文件來進行認證。同時還需要設置api server組件啟動參數：“–kubelet-client-certificate”和“–kubelet-client-key”。在認證文件中一個用戶可以屬于多個用戶組，比如下面例子產生的認證：

openssl req -new -key jbeda.pem -outjbeda-csr.pem -subj “/CN=jbeda/O=app1/O=app2”

這個例子創(chuàng)建了csr認證文件，這個csr認證文件作用于用戶jbeda，這個用戶屬于兩個用戶組，分別是app1和app2。

可以啟用令牌認證，這時需要通過命令“–runtime-config=authentication.k8s.io/v1beta1=true“啟用api server組件authentication.k8s.io/v1beta1相關的API，還需要啟用kubelet組件的“–authentication-token-webhook”、“–kubeconfig”、“–require-kubeconfig”三個參數。

kubeconfig參數：設置kubelet配置文件路徑，這個配置文件用來告訴kubelet組件api server組件的位置，默認路徑是。

require-kubeconfig參數：這是一個布爾類型參數，可以設置成true或者false，如果設置成true，那么表示啟用kubeconfig參數，從kubeconfig參數設置的配置文件中查找api server組件，如果設置成false，那么表示使用kubelet另外一個參數“api-servers”來查找api server組件位置。

在kubernetes源代碼中，有一個錯誤的注釋：

func NewKubeletServer() *KubeletServer {

versioned:= &v1alpha1.KubeletConfiguration{}

api.Scheme.Default(versioned)

config:= componentconfig.KubeletConfiguration{}

api.Scheme.Convert(versioned,&config, nil)

return&KubeletServer{

KubeConfig:           flag.NewStringFlag(“/var/lib/kubelet/kubeconfig”),

RequireKubeConfig:    false, // in 1.5, default to true

KubeletConfiguration:config,

}

}

這里面對RequireKubeConfig參數默認值的設置是false，但是在注釋中寫的確實true。

啟用令牌認證后，kubelet會調用TokenReview API來進行令牌認證。

下面是一個kubeconfig文件格式樣例：

clusters:

-name: name-of-remote-authn-service

cluster:

certificate-authority: /path/to/ca.pem         # 校驗遠程服務的認證文件

server: https://authn.example.com/authenticate # 遠程服務訪問https路徑

users:

-name: name-of-api-server

user:

client-certificate: /path/to/cert.pem    # webhook插件使用的認證文件

client-key: /path/to/key.pem         # 認證文件對應的密鑰文件

current-context: webhook

contexts:

– context:

cluster: name-of-remote-authn-service

user: name-of-api-sever

name: webhook

認證請求格式樣例如下：

{

“apiVersion”: “authentication.k8s.io/v1beta1”,

“kind”: “TokenReview”,

“spec”: {

“token”: “(BEARERTOKEN)”

}

}

成功的認證響應如下：

{

“apiVersion”: “authentication.k8s.io/v1beta1”,

“kind”: “TokenReview”,

“status”: {

“authenticated”: true,

“user”: {

“username”: “[email protected]”,

“uid”: “42”,

“groups”: [

“developers”,

“qa”

],

“extra”: {

“extrafield1”: [

“extravalue1”,

“extravalue2”

]

}

}

}

}

失敗的認證響應如下：

{

“apiVersion”: “authentication.k8s.io/v1beta1”,

“kind”: “TokenReview”,

“status”: {

“authenticated”: false

}

}

授權

任何請求被成功認證后才會被授權，包括匿名認證請求。默認的授權模式是AlwaysAllow，意味著允許任何請求。其實對于API的請求是需要進行更細粒度劃分和授權的，有下面兩點原因：

雖然允許匿名用戶請求，但是應該限制匿名用戶可以訪問的API。

雖然允許認證用戶請求，但是不同認證用戶應該可以訪問不同的API，而不能所有認證用戶只能訪問相同的API。

要想進行API權限控制，需要通過命令“–runtime-config= authorization.k8s.io /v1beta1=true“啟用api server組件authorization.k8s.io/v1beta1相關的API，還需要將授權模式參數“–authorization-mode”設置成Webhook，然后啟用kubelet組件的“–kubeconfig”和“–require-kubeconfig”兩個參數，這兩個參數的作用在上面認證章節(jié)已經詳細介紹過了，這里不再介紹。

Kubelet接著就會調用api server組件的SubjectAccessReviewAPI來判斷哪個請求需要進行授權控制。

請求動作類型是根據HTTP訪問類型進行劃分的，如下面表格所示：

HTTP verb request verbPOST createGET, HEAD getPUT updatePATCH patchDELETE delete

資源訪問請求是根據不同請求路徑來進行劃分的，如下面表格所示：

Kubelet API 資源名稱 子資源名稱/stats/* nodes stats/metrics/* nodes metrics/logs/* nodes log/spec/* nodes specall others nodes proxy

對于資源訪問請求，訪問時名字空間和API組這兩個屬性永遠都是空值，資源名稱的屬性值就是kubelet所在節(jié)點對象名稱。

要是想讓kubelete API可以進行權限控制，還需要確保api server組件已經啟用了“–kubelet-client-certificate”和“–kubelet-client-key”連個參數，

kubelet-client-certificate參數：客戶端認證文件路徑

kubelet-client-key參數：客戶端密鑰文件路徑

還確?？蛻舳吮皇跈嗫梢栽L問下面屬性：

verb=*, resource=nodes,subresource=proxy

verb=*, resource=nodes, subresource=stats

verb=*, resource=nodes,subresource=log

verb=*, resource=nodes,subresource=spec

verb=*, resource=nodes,subresource=metrics

總結

Kubernetes1.5中增加了kubele API的認證和授權功能，從中可以發(fā)現社區(qū)對K8S在生產環(huán)節(jié)中安全性的設計日趨完善，也說明有越來越多的客戶在生產環(huán)境中使用K8S了。經常訪問K8S社區(qū)就會發(fā)現，在基礎功能日趨完善的情況下，K8S社區(qū)現在對于跨云（Federation）和安全認證（Security/Auth）這兩方面有了長足的進步，將來的K8S會適合更多的生產環(huán)境，會成為一款特別受歡迎的容器編排開源軟件產品。

當前標題：Kubernetes1.5新增特性KubeletAPI增加認證和授權能力
網站網址：http://uogjgqi.cn/article/dpdidhh.html