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”: “[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”兩個引數，這兩個引數的作用在上面認證章節已經詳細介紹過了，這裡不再介紹。
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會適合更多的生產環境，會成為一款特別受歡迎的容器編排