Kubernetes1.5新特性（一）:Kubelet API增長認證和受權能力

背景介紹

在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的請求都以匿名方式進行，系統會使用默認匿名用戶和默認用戶組來進行訪問，默認用戶名「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」

這個例子建立了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」: 「janedoe@example.com」,

「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」兩個參數，這兩個參數的做用在上面認證章節已經詳細介紹過了，這裏再也不介紹。

Kubelet接着就會調用api server組件的SubjectAccessReviewAPI來判斷哪一個請求須要進行受權控制。

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

HTTP verb	request verb
POST	create
GET, HEAD	get
PUT	update
PATCH	patch
DELETE	delete

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

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

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

要是想讓kubelete API能夠進行權限控制，還須要確保api server組件已經啓用了「–kubelet-client-certificate」和「–kubelet-client-key」連個參數，

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

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

還確保客戶端被受權能夠訪問下面屬性：

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的認證和受權功能，從中能夠發現社區對K8S在生產環節中安全性的設計日趨完善，也說明有愈來愈多的客戶在生產環境中使用K8S了。常常訪問K8S社區就會發現，在基礎功能日趨完善的狀況下，K8S社區如今對於跨雲（Federation）和安全認證（Security/Auth）這兩方面有了長足的進步，未來的K8S會適合更多的生產環境，會成爲一款特別受歡迎的容器編排開源軟件產品。