1. 程式人生 > >kubernetes1.5新特性:kubelet API增加認證和授權能力

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會適合更多的生產環境,會成為一款特別受歡迎的容器編排開源軟體產品。