帶你讀《雲原生應用開發 Operator原理與實踐》第二章 Operator 原理2.3 Kube-APIServer 介紹（二）

2.3.2         認證

1. 認證中使用的使用者

Kubernetes叢集中有兩種使用者：一種是由 Kubernetes管理的 ServiceAccount；另一種是普通使用者。普通使用者是由叢集之外的服務管理的，比如存儲在Keystone中的使用者、存儲在檔案中的使用者和存儲在 ldap中的使用者等。 所有的 API請求中都綁定了一個ServiceAccount或普通使用者，如果都未綁定，就是一個使用匿名使用者的請求。

ServiceAccount與它關聯的請求中的使用者是什麼樣的呢？ServiceAccoount在Kuberentes中關聯着一個 Secret，這個 Secret中包括一個 JWT格式的 Token，它會使用 Token中的 Payload中的 Sub 字段作為請求使用者的名稱。下面是對 Secret中的 Token解析的一個示例，請求所使用的使用者名是 system:serviceaccount:default:default，見代碼清單 2-60。

{

"iss":"kubernetes/serviceaccount","kubernetes.io/serviceaccount/namespace":"default","kubernetes.io/serviceaccount/secret.name":"default-token-bxzg6","kubernetes.io/serviceaccount/service-account.name":"default","kubernetes.io/serviceaccount/service-account.uid":"a96a30e3-3ee0-44cf-

99b2-1ad4bdbc7632",

"sub":"system:serviceaccount:default:default"

}

普通使用者有多種方式攜帶認證資訊去通路    APIServer。以用戶端證書的方式為例，請求中如果攜帶了用戶端證書，并且證書是由叢集的 CA憑證（Certification   Authority）簽發的，那麼這個請求的認證會通過，它會使用證書中的 Subject字段作為使用者的名稱。代碼清單 2-61是一個證書的示例，示例中攜帶的使用者名是kcp（Subject:O=system:kcp，CN=kcp）。

Certificate:

Data:

Version:3(0x2)SerialNumber:

08:e2:5b:3a:2c:8c:6c:06:80:f8:aa:1b:81:76:93:4f

SignatureAlgorithm:sha256WithRSAEncryptionIssuer:CN=kubernetes

Validity

NotBefore:Mar305:59:422021GMT

NotAfter:Jul1109:37:382030GMT

Subject:O=system:kcp,CN=kcp

......

2. 認證政策

（1）       X509 用戶端證書認證

用戶端證書認證是雙向認證，伺服器端需要驗證用戶端證書的正确性，用戶端需要驗證伺服器端證書的正确性。用戶端證書認證方式可以通過Kube-Apiserver的--client- ca-file參數啟用，它指向的檔案用來驗證提供給API伺服器的用戶端證書。當請求中攜帶的用戶端證書通過了認證時，請求關聯的使用者名就是證書中的Subject字段的内容。我們可以使用代碼清單 2-62檢視證書内容

opensslx509-in< 證書> -text-noout

（2）      靜态 Token檔案

靜态 Token檔案認證方式可以通過 --token-auth-file 參數啟用，在這個檔案中存放着沒有時間限制的 BearerToken，如果想變更 Token，則必須要重新開機 APIServer。代碼清單 2-63是一個 Token檔案的示例，每一行包括 Token、使用者名和使用者ID。JGaOWpJuyBL8NXmeA9V341JOCkHJbOTf,system:kubectl-kcpm1,system:kubectl-kcpm1

通路 APIServer時在HTTP請求頭上加入 Authorization的請求頭， 值的格式是Bearer<Token>，上面的Token見代碼清單 2-64。

curl-H"Authorization:BearerJGaOWpJuyBL8NXmeA9V341JOCkHJbOTf"-khttps://127.0.0.1:6443/

（3）       引導 Token

我們在建立叢集或是将新節點加入叢集時，新節點上的元件要與APIServer進行通信（如Kubelet），但通信需要證書，手動簽發證書比較麻煩。為了簡化這個過程，Kubernetes1.4之後的版本會通過新節點發送請求的方式為新節點簽發證書。而發送請求獲驗證書的請求時使用的BearerToken叫作BootstrapToken，這種Token在Kube-SystemNamespace下有一個對應的Secret。Controller-Manager中有一個TokenCleaner的Controller，它會将那些已經過期的 BootstrapToken掉。

Token的格式是 [a-z0-9]{6}.[a-z0-9]{16}，Token的前半部分是 TokenID，通過前半部分能找到 UI應的 Secret；第二部分是 TokenSecret，儲存在 Secret中。以Kubeadm建立的 tokencwb0ly.cqdj5l0k2qa19evv為例，在 Kube-System的 Namespace下會有一個名字為 bootstrap-token-cwb0ly的 Secret，内容見代碼清單2-65。

apiVersion:v1data:

auth-extra-groups:system:bootstrappers:kubeadm:default-node-tokenexpiration:2021-03-13T13:44:23+08:00

token-id:cwb0ly

token-secret:cqdj5l0k2qa19evvusage-bootstrap-authentication:trueusage-bootstrap-signing:true

kind:Secretmetadata:

manager:kubeadm

operation:Update

name:bootstrap-token-cwb0lynamespace:kube-system

使用該 Token作為 Authorization請求頭通路 APIServer，請求認證通過後關聯到的使用者名的格式是 bootstrap-token-<token-id>，即 system:bootstrap:cwb0ly，請求示例見代碼清單 2-66。

curl-H"Authorization:Bearercwb0ly.cqdj5l0k2qa19evv"-k

https://127.0.0.1:6443/

要想使用引導 Token 認證，需要在 APIServer 啟動的時候添加 --enable-bootstrap-token-auth啟動參數，如果想使用 TokenClearController，需要在 Controller-Manager的啟動參數中添加 --controllers=*，tokencleaner。