Kubernetes使用者端認證——基於CA證書的雙向認證方式

1、Kubernetes 認證方式

　　Kubernetes叢集的存取許可權控制由API Server負責，API Server的存取許可權控制由身份驗證(Authentication)、授權(Authorization)和准入控制（Admission control）三個步驟組成，這個三個步驟是按序進行的（詳細介紹請參見《(轉)使用kubectl存取Kubernetes叢集時的身份驗證和授權》）。

其中身份驗證這個環節它面對的輸入是整個http request，它負責對來自client的請求進行身份校驗，支援的方法包括：

CA 認證，基於CA根證書籤名的雙向數位憑證認證
Token認證，通過Token識別每個合法的使用者
Basic認證

　　API Server啟動時，可以指定一種Authentication方法，也可以指定多種方法。如果指定了多種方法，那麼APIServer將會逐個使用這些方法對使用者端請求進行驗證，只要請求資料通過其中一種方法的驗證，API Server就會認為Authentication成功；在較新版本kubeadm引導啟動的k8s叢集的API Server初始設定中，預設支援CA認證和Token認證兩種身份驗證方式。在這個環節，API Server會通過client證書或http header中的欄位(比如ServiceAccount的JWTToken)來識別出請求的「使用者身份」，包括」user」、」group」等，這些資訊將在後面的授權和准入控制環節用到。

在Kubernetes中，Kubectl和API Server、Kubelet和API Server、API Server和Etcd、Kube-Scheduler和API Server、Kube-Controller-Manager和API Server以及Kube-Proxy和API Server之間是基於CA根證書籤名的雙向數位憑證方式進行認證，此方式是最為嚴格和安全的叢集安全設定方式，也是我們本文介紹的主角；在Kubernetes中，整合的元件和API Server之間也可以選擇設定基於CA根證書籤名的雙向數位憑證方式進行認證，比如Metrics Servser；在Kubernetes中，Pod和API Server之間如果沒有設定基於CA根證書籤名的雙向數位憑證方式進行認證的話，則預設通過Token方式（ServiceAccount的JWTToken)）進行認證。

2、Kubernetes CA 認證涉及相關知識

在詳細介紹Kubernetes CA認證之前，我們先簡述下和Kubernetes CA認證相關的知識。

2.1 CA證書相關知識

對稱加密：指加密與解密使用同一金鑰的方式，速度快，但金鑰管理困難。
非對稱加密：指加密和解密使用不同金鑰的方式，速度慢。公鑰和私鑰匙一一對應的，一對公鑰和私鑰統稱為金鑰對。由公鑰進行加密的密文，必須使用與該公鑰配對的私鑰才能解密。金鑰對中的兩個金鑰之間具有非常密切的關係——數學上關係——公鑰和私鑰匙不能分佈單獨生成的。它有兩種用途：(1)加密傳輸過程：公鑰加密，私鑰解密；(2)簽名過程：私鑰加密，公鑰解密。
混合加密：將對稱金鑰與非對稱金鑰結合起來，這種系統結合了兩者的優勢。比如，SSL/TLS使用混合加密（Hybrid Encryption）的方式來保證通訊的安全性，在混合加密中，使用非對稱加密演演算法來協商對稱金鑰，然後使用對稱加密演演算法來對通訊過程中的資料進行加密和解密，以提供更高的安全性和效率。
數位簽章：數位簽章是一種用於確保數位資訊的完整性、身份認證和不可抵賴性的加密技術。數位簽章是基於公鑰加密和非對稱金鑰技術實現的，常被用於驗證數位檔案、軟體、電子郵件等的真實性和完整性。數位簽章的基本原理是將原始資料通過雜湊函數（Hash Function）生成一個摘要（Digest），然後使用傳送者的私鑰對摘要進行加密，生成數位簽章。接著，將原始資料和數位簽章一起傳輸給接收者。接收者收到資料後，使用傳送者的公鑰對數位簽章進行解密，得到摘要。然後，接收者對接收到的原始資料使用相同的雜湊函數生成另一個摘要，將兩個摘要進行比較，如果兩個摘要一致，則表明原始資料沒有被篡改過，數位簽章也是合法的，否則就表明原始資料已經被篡改過或者數位簽章不合法。要正確的使用數位簽章，有一個大前提，那就是用於驗證簽名的公鑰必須屬於真正的傳送者。
證書：數位憑證是基於公鑰加密和非對稱金鑰技術實現的，通過數位憑證可以驗證一個數位實體的身份資訊，簡單來說證書就是為公鑰加上數位簽章。它是由數位憑證頒發機構（CA，Certificate Authority）簽發的一種數位檔案，包含了證書持有者的身份資訊和公鑰等關鍵資訊。數位憑證通常包含以下資訊：
- 證書頒發機構的名稱和公鑰。
- 證書持有者的名稱、電子郵件地址和公鑰等身份資訊。
- 證書有效期限和用途。
- 證書頒發機構的數位簽章。

CA（證書頒發機構）：CA是一個機構，專門為其他人簽發證書，這個證書儲存其他人的公鑰，確保了公鑰的來源且沒有被篡改。CA本身有自己的公私鑰對，私鑰用於簽發其他證書，公鑰用於驗證證書，CA公鑰同樣需要保護，這就是CA證書。那麼CA證書是誰簽發呢，從簽名的原理來看，必然存在CA自己給自己簽名，這就是根CA證書。根CA是非常寶貴的，通常出於安全的考慮會簽發一些中間CA證書，然後由中間CA簽發終端使用者證書，這樣就構成了一個信任鏈。接收者信任某個CA證書，那麼由此CA簽發的證書就都被信任。公信的根CA全球只有有限的一些，它們通過第三方機構審計，具有權威性和公正性，通常作業系統或瀏覽器已經內建安裝，由這些根CA簽發的證書都會被信任。使用者也可以自行安裝信任的證書，其風險需要使用者自己承擔，一定要確保證書來源可靠。
根證書（自簽名證書）：根證書是CA認證中心給自己頒發的證書,是信任鏈的起始點。

2.2 HTTPS雙向認證流程

　　Kubernetes CA認證也叫HTTPS證書認證，其認證原理便是HTTPS雙向認證，下面著重說下HTTPS雙向認證流程：

1.使用者端發起建⽴HTTPS連線請求，將SSL協定版本的資訊傳送給伺服器端；
2.伺服器端將本機的公鑰證書（server.crt）傳送給使用者端；
3. 使用者端通過自己的根證書（ca.crt）驗證伺服器端的公鑰證書（server.crt）的合法性，取出伺服器端公鑰。
4. 使用者端將使用者端公鑰證書（client.crt）傳送給伺服器端；
5. 伺服器端使⽤根證書（ca.crt）解密使用者端公鑰證書，拿到使用者端公鑰；
6. 使用者端傳送⾃⼰⽀持的加密⽅案給伺服器端；
7. 伺服器端根據⾃⼰和使用者端的能⼒，選擇⼀個雙⽅都能接受的加密⽅案，使⽤使用者端的公鑰加密後傳送給使用者端；
8. 使用者端使⽤⾃⼰的私鑰解密加密⽅案，⽣成⼀個亂數R，使⽤伺服器公鑰加密後傳給伺服器端；
9. 伺服器端⽤⾃⼰的私鑰去解密這個密⽂，得到了金鑰R；
10. 伺服器端和使用者端在後續通訊過程中就使⽤這個金鑰R進⾏通訊了。

注意：預設情況下，HTTPS是先進行TCP三次握手，再進行TLS四次握手。

3、Kubernetes 基於CA根證書籤名的雙向數位憑證認證

下面以Kubectl（使用者端）和API Server（伺服器端）認證為例，講解基於CA根證書籤名的雙向數位憑證認證。

3.1 API Server證書設定

使用Kubeadm初始化的Kubernetes叢集中，API Server是以靜態Pod的形式執行在Master Node上。可以在Master Node上找到其定義檔案/etc/kubernetes/manifests/kube-apiserver.yaml，其中啟動命令引數部分如下：

spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.20.30.31
    - --allow-privileged=true
    - --audit-log-maxage=30
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100
    - --audit-log-path=/data/lc/log/t-audit.log
    - --authorization-mode=Node,RBAC
    - --bind-address=0.0.0.0
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/ssl/etcd/ssl/ca.pem
    - --etcd-certfile=/etc/ssl/etcd/ssl/node-node1.pem
    - --etcd-keyfile=/etc/ssl/etcd/ssl/node-node1-key.pem
    - --etcd-servers=https://10.20.30.31:2379
    - --feature-gates=ExpandCSIVolumes=true,RotateKubeletServerCertificate=true,RemoveSelfLink=false,SuspendJob=true
    - --insecure-port=0
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-issuer=https://kubernetes.default.svc.cluster.local
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
    - --service-cluster-ip-range=10.233.0.0/18
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key

注意："API Server" 和 "kube-apiserver" 可以視為同義詞，都是 Kubernetes 中核心的 API 處理器，但 "kube-apiserver" 是 Kubernetes 中預設的 API Server 實現。

API Server作為伺服器端時，我們注意到有如下三個啟動引數：

--client-ca-file: 指定CA根證書檔案為/etc/kubernetes/pki/ca.crt，內建CA公鑰用於驗證某證書是否是CA簽發的證書，Kubectl和Kube-Apiserver之間認證的話，ca.crt用於驗證Kubectl的使用者端證書是否是CA簽發的證書。
--tls-cert-file：指定Kube-Apiserver證書檔案為/etc/kubernetes/pki/apiserver.crt
--tls-private-key-file: 指定Kube-Apiserver私鑰檔案為/etc/kubernetes/pki/apiserver.key

在Master Node上進入/etc/kubernetes/pki/目錄：

[root@node1 pki]# pwd
/etc/kubernetes/pki
[root@node1 pki]# ls
apiserver.crt  apiserver-kubelet-client.crt  ca.crt  front-proxy-ca.crt  front-proxy-client.crt  sa.key
apiserver.key  apiserver-kubelet-client.key  ca.key  front-proxy-ca.key  front-proxy-client.key  sa.pub

檢視CA根證書ca.crt：

[root@node1 pki]# openssl x509 -noout -text -in ca.crt 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Apr 19 03:11:19 2022 GMT
            Not After : Apr 16 03:11:19 2032 GMT
        Subject: CN=kubernetes
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:bd:27:a0:73:45:58:b9:f4:90:27:53:77:02:ff:
                    8e:9b:f3:5a:14:d7:85:08:c8:17:8f:cb:66:54:61:
                    47:d3:59:3c:97:c0:bb:a0:63:c6:2a:eb:cb:07:ec:
                    f7:b1:06:e2:68:07:71:67:93:10:27:80:c0:2f:e2:
                    93:3f:34:ab:de:68:eb:3a:af:71:5e:18:71:be:e0:
                    06:9f:3c:97:f7:52:5e:fd:8a:2d:de:fd:bc:5e:be:
                    c1:51:7e:38:9b:ac:25:79:68:00:26:a4:61:e7:5f:
                    30:32:bb:af:39:fb:aa:58:eb:98:b6:ac:ab:31:50:
                    6c:bd:64:38:2d:16:5e:96:db:ba:ce:d1:ce:90:83:
                    a6:03:76:55:e7:af:6c:8d:2e:c5:52:18:8b:77:6f:
                    d3:fb:1c:cb:c9:01:8b:8f:7b:4d:a4:0c:07:8d:0d:
                    18:69:ac:1b:14:90:61:99:f8:8f:b8:ca:52:2e:2b:
                    8a:87:7a:15:5e:b1:3f:1a:1b:8e:a3:87:dc:3d:f1:
                    1a:3c:30:8f:cf:2e:20:eb:d9:2c:a4:5f:80:6e:cb:
                    f1:e1:db:68:f3:a7:40:88:f8:7f:df:0d:1d:af:ac:
                    f2:aa:ec:12:65:69:8e:c7:2a:42:2e:38:e6:16:b5:
                    1f:de:26:de:4f:e8:ec:c6:76:22:ce:3c:59:4d:46:
                    6e:49
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                D2:9E:9D:50:19:5E:24:92:CC:3D:A4:F3:3C:54:E4:EA:0D:FF:70:77
    Signature Algorithm: sha256WithRSAEncryption
         25:b2:9b:94:fb:0f:5c:50:2f:cd:4f:b3:54:97:3c:ee:b3:65:
         f7:19:4a:6a:d5:ad:48:0b:f9:8e:56:0f:60:a3:7e:6e:48:62:
         9b:60:1e:a3:91:d7:60:f7:96:43:5c:5b:ab:96:99:cd:2d:86:
         19:de:e7:12:2e:17:2b:b6:93:50:e7:a3:74:3d:9e:cf:b5:58:
         88:dc:6a:29:48:7d:57:2d:e6:a6:9b:ee:2f:ce:fa:5e:74:ba:
         42:40:72:c5:fa:37:5a:03:f8:19:27:69:b3:87:be:2f:ca:ae:
         9d:8e:ae:83:c3:8d:1a:45:55:23:b5:c9:d6:08:9b:6e:f7:0a:
         ee:12:67:b2:24:52:e1:a8:01:35:82:0b:1d:5f:10:56:b4:b5:
         ea:4a:b8:8f:0e:4c:93:dd:a8:71:37:32:27:66:20:ca:ec:5d:
         f7:14:9e:8a:b7:82:18:b7:55:38:4a:a5:4b:1c:73:d7:b5:7e:
         a1:f5:f8:e3:4c:ab:73:62:41:23:12:91:42:12:06:8d:84:81:
         4d:30:d3:dc:14:7c:c7:a4:ab:76:fd:c7:3b:1c:42:eb:7b:23:
         92:1a:11:fe:63:12:22:ea:76:d2:fd:e1:9d:0b:74:77:6b:04:
         9f:a1:96:49:bc:f1:fc:9c:55:8f:19:ac:d5:f0:ac:e4:3c:d7:
         bd:5e:f7:65

注意：檢視證書的方式有很多，不只可以通過openssl工具，也可以通過線上SSL網站解析證書，比如：SSLeye。

驗證CA根證書ca.crt證書的合法性：

[root@node1 pki]# openssl verify -CAfile ca.crt ca.crt 
ca.crt: OK

注意：我們知道驗證證書合法性，就是用公鑰驗證證書的數位簽章，由於CA根證書是自簽名證書，公鑰和數位簽章資訊都在ca.crt證書檔案中，所以用以上命令驗證ca.crt證書的合法性即可。

檢視ApiServer的證書apiserver.crt：

[root@node1 pki]# openssl x509 -noout -text -in apiserver.crt 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 7066543051370023677 (0x621167770eea4afd)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Apr 19 03:11:19 2022 GMT
            Not After : Apr 16 03:11:19 2032 GMT
        Subject: CN=kube-apiserver
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                ......
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                keyid:D2:9E:9D:50:19:5E:24:92:CC:3D:A4:F3:3C:54:E4:EA:0D:FF:70:77

            X509v3 Subject Alternative Name: 
                DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:lb.xxx.local, DNS:localhost, DNS:node1, DNS:node1.cluster.local, IP Address:10.233.0.1, IP Address:10.20.30.31, IP Address:127.0.0.1
   ......

驗證apiserver.crt由ca.crt簽發：

[root@node1 pki]# openssl verify -CAfile ca.crt apiserver.crt 
apiserver.crt: OK

3.2 生成Kubectl使用者端私鑰和證書

使用者端要通過HTTPS證書雙向認證的形式存取ApiServer需要生成使用者端的私鑰和證書，其中使用者端證書的在生成時-CA引數要指定為ApiServer的CA根證書檔案/etc/kubernetes/pki/ca.crt，-CAkey引數要指定為Api Server的CA key /etc/kubernetes/pki/ca.key。

下面生成使用者端私鑰和證書：

cd /etc/kubernetes/pki/
// 生成kubectl使用者端私鑰
openssl genrsa -out client.key 2048  
// 基於kubectl使用者端私鑰生成kubectl使用者端證書籤名請求檔案client.csr，其中CN代表k8s使用者，O代表k8s組
openssl req -new -key client.key -subj "/CN=10.20.30.31/O=system:masters" -out client.csr
// 基於證書請求檔案、根CA證書、根CA私鑰純生成kubectl使用者端證書
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 3650

注意 1：在 X.509 數位憑證中，Subject 欄位是用於表示證書擁有者的欄位之一，通常包含多個子欄位，用於描述證書擁有者的不同屬性。下面是 Subject 欄位中常見的子欄位以及它們的含義：

C (Country): 表示證書擁有者所在的國家或地區的 ISO 3166-1 程式碼。

ST (State or Province): 表示證書擁有者所在的州或省份的全名或簡稱。

L (Locality): 表示證書擁有者所在的城市或城鎮的名稱。

O (Organization Name): 表示證書擁有者的組織名稱。

OU (Organizational Unit Name): 表示證書擁有者的組織中的部門或單位名稱。

CN (Common Name): 表示證書擁有者的通用名稱，通常是證書關聯的域名。

Email: 表示證書擁有者的電子郵件地址。

除了上述常見的子欄位外，Subject 欄位還可以包含其他自定義的子欄位，用於描述證書擁有者的其他屬性。需要注意的是，Subject 欄位中的屬性並非必須全部存在，具體哪些屬性需要包含取決於證書頒發機構的要求。在生成kubectl使用者端證書籤名請求檔案時，只是指定了證書擁有者的CN和O屬性，分別代表k8s使用者和組，其中組資訊確定了kubectl使用者端在k8s叢集中的角色。（詳細介紹請參見《(轉)使用kubectl存取Kubernetes叢集時的身份驗證和授權》）

注意 2：.srl 是 OpenSSL 工具生成 X.509數位憑證時自動生成的一個檔案，用於記錄證書的序列號。在生成證書時，每個證書都會被分配一個唯一的序列號，該序列號會被包含在證書中，並且儲存在 .srl 檔案中。由於 .srl 檔案僅包含證書的序列號，因此通常可以安全地刪除該檔案，而不會影響現有的證書。

檢視生成的kubectl使用者端證書client.crt：

[root@node1 pki]# openssl x509 -noout -text -in client.crt 
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            fb:f7:2d:e5:58:8c:23:d5
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Apr  8 12:15:49 2023 GMT
            Not After : Apr  5 12:15:49 2033 GMT
        Subject: CN=10.20.30.31, O=system:masters
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                ......
    Signature Algorithm: sha256WithRSAEncryption
         ......

驗證kubectl使用者端證書client.crt是由ca.crt簽發：

[root@node1 pki]# openssl verify -CAfile ca.crt client.crt 
client.crt: OK

3.3 使用生成的Kubectl使用者端私鑰和證書存取ApiServer

[root@node1 pki]# kubectl --server=https://10.20.30.31:6443 \
> --certificate-authority=ca.crt  \
> --client-certificate=client.crt \
> --client-key=client.key \
> get nodes
NAME           STATUS   ROLES                         AGE    VERSION
harbor-slave   Ready    worker                        11d    v1.21.5
node1          Ready    control-plane,master,worker   354d   v1.21.5

注意 1：如果執行kubectl使用者端命令報如下錯誤：
[root@node1 pki]# kubectl --server=https://10.20.30.31:6443 \
> --certificate-authority=ca.crt  \
> --client-certificate=client.crt \
> --client-key=client.key \
> get nodes
Error in configuration: 
* client-cert-data and client-cert are both specified for kubernetes-admin. client-cert-data will override.
* client-key-data and client-key are both specified for kubernetes-admin; client-key-data will override
請通過以下命令檢視 kubectl 是否之前加入過別的 k8s 叢集：
[root@node1 pki]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.20.30.31:6443
  name: cluster.local
contexts:
- context:
    cluster: cluster.local
    user: kubernetes-admin
  name: [email protected]
current-context: [email protected]
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
在問題節點執行如下命令，用於清空 kubectl 的設定（或者一般情況下直接刪除/root/.kube/config檔案即可），執行完以下命令後再執行kubectl命令便不會再報此錯誤。
$ /usr/bin/kubectl config unset users
$ /usr/bin/kubectl config unset clusters
$ /usr/bin/kubectl config unset contexts
注意 2：本文主要講解基於CA證書的雙向認證方式，如果執行kubectl使用者端命令報cannot list resource "nodes" in API錯誤，請檢查kubectl使用者端證書擁有者所屬組關聯的role是否擁有存取node資源許可權。

4、總結

　　Kubernetes元件之間使用基於CA證書的雙向認證方式可以帶來以下好處：

更高的安全性：雙向認證可以確保使用者端和伺服器之間的通訊是雙向加密的，從而提高了通訊的安全性，減少了資料洩露和中間人攻擊等風險。
認證使用者端身份：使用雙向認證可以讓伺服器驗證使用者端的身份，並且只有被授權的使用者端才能存取伺服器，從而減少了惡意攻擊和未經授權的存取。
降低攻擊風險：在雙向認證中，伺服器會要求使用者端提供證書，這樣可以避免一些惡意攻擊，比如偽造證書的攻擊等。
確保資料完整性：雙向認證可以確保使用者端和伺服器之間的通訊是完整的，沒有被篡改或修改過的資料。

　　總之，雙向認證可以提供更高的安全性和保護，減少了攻擊風險，同時確保了資料的完整性和保密性，因此在 Kubernetes 中使用雙向認證是一種非常有效的安全措施。

參考：Kubernetes構建自定義admission webhook

參考：(轉)使用kubectl存取Kubernetes叢集時的身份驗證和授權

參考：給面試官上一課：HTTPS是先進行TCP三次握手，再進行TLS四次握手