技術文章 » Kubernetes 證書詳解

Kubernetes 證書詳解

2023-05-26 06:01:10

K8S 證書介紹

在 Kube-apiserver 中提供了很多認證方式，其中最常用的就是 TLS 認證，當然也有 BootstrapToken，BasicAuth 認證等，只要有一個認證通過，那麼 Kube-apiserver 即認為認證通過。下面就主要講解 TLS 認證。

如果你是使用 kubeadm 安裝的 Kubernetes， 則會自動生成叢集所需的證書。但是如果是通過二進位制搭建，所有的證書是需要自己生成的，這裡我們說說叢集必需的證書。

在瞭解 Kubernetes 證書之前，需要先了解什麼是 「單向 TLS 認證」 和 「雙向 TLS 認證」

  • 伺服器單向認證：只需要伺服器端提供證書，使用者端通過伺服器端證書驗證服務的身份，但伺服器並不驗證使用者端的身份。這種情況一般適用於對 Internet 開放的服務，例如搜尋引擎網站，任何使用者端都可以連線到伺服器上進行存取，但使用者端需要驗證伺服器的身份，以避免連線到偽造的惡意伺服器。
  • 雙向 TLS 認證：除了使用者端需要驗證伺服器的證書，伺服器也要通過使用者端證書驗證使用者端的身份。這種情況下伺服器提供的是敏感資訊，只允許特定身份的使用者端存取。開啟伺服器端驗證使用者端預設是關閉的，需要在伺服器端開啟認證設定。

Kubernetes 為了安全性，都是採用雙向認證。通常我們使用 Kubeadm 在部署 Kubernetes 時候，Kubeadm 會自動生成叢集所需要的證書，下面我們就這些證書一一給大家進行講解。

這是我們用 Kubeadm 搭建完一個叢集後在 /etc/kubernetes 目錄下所生成的檔案

$ tree kubernetes/
kubernetes/
|-- admin.conf
|-- controller-manager.conf
|-- kubelet.conf
|-- scheduler.conf
|-- manifests
|   |-- etcd.yaml
|   |-- kube-apiserver.yaml
|   |-- kube-controller-manager.yaml
|   `-- kube-scheduler.yaml
|-- pki
|   |-- apiserver.crt
|   |-- apiserver-etcd-client.crt
|   |-- apiserver-etcd-client.key
|   |-- apiserver.key
|   |-- apiserver-kubelet-client.crt
|   |-- apiserver-kubelet-client.key
|   |-- ca.crt
|   |-- ca.key
|   |-- etcd
|   |   |-- ca.crt
|   |   |-- ca.key
|   |   |-- healthcheck-client.crt
|   |   |-- healthcheck-client.key
|   |   |-- peer.crt
|   |   |-- peer.key
|   |   |-- server.crt
|   |   `-- server.key
|   |-- front-proxy-ca.crt
|   |-- front-proxy-ca.key
|   |-- front-proxy-client.crt
|   |-- front-proxy-client.key
|   |-- sa.key
|   `-- sa.pub

下面我們根據這個 Kubernetes 的元件之間通訊圖來一一講解每個證書的作用。本文基於 Kubernetes:v1.22.17

CA證書

Kubeadm 安裝的叢集中我們都是用 3 套 CA 證書來管理和簽發其他證書，一套 CA 給 ETCD 使用，一套是給 Kuberntes 內部元件使用，還有一套是給設定聚合層使用的，當然如果你覺得管理 3 套 CA 比較麻煩，您也可以用一套來管理。

Etcd 證書

ca.crt  ca.key  healthcheck-client.crt  healthcheck-client.key  peer.crt  peer.key  server.crt  server.key

etcd 證書位於 /etc/kubernetes/pki/etcd 目錄下，我們根據 etcd 的 static-pod yaml 設定解釋下證書的作用

spec:
  containers:
  - command:
    - etcd
    - --advertise-client-urls=https://10.0.4.3:2379
    - --cert-file=/etc/kubernetes/pki/etcd/server.crt
    - --client-cert-auth=true
    - --data-dir=/var/lib/etcd
    - --initial-advertise-peer-urls=https://10.0.4.3:2380
    - --initial-cluster=vm-4-3-centos=https://10.0.4.3:2380
    - --key-file=/etc/kubernetes/pki/etcd/server.key
    - --listen-client-urls=https://127.0.0.1:2379,https://10.0.4.3:2379
    - --listen-peer-urls=https://10.0.4.3:2380
    - --name=vm-4-3-centos
    - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
    - --peer-client-cert-auth=true
    - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
    - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    - --snapshot-count=10000
    - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    image: k8s.gcr.io/etcd:3.3.10
    imagePullPolicy: IfNotPresent
    livenessProbe:
      exec:
        command:
        - /bin/sh
        - -ec
        - ETCDCTL_API=3 etcdctl --endpoints=https://[127.0.0.1]:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt
          --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.key
          get foo
      failureThreshold: 8

Etcd 根證書

Etcd 根證書用於簽發其餘證書，比如伺服器端證書，使用者端證書等

ca.crt   ca.key

Etcd 伺服器端證書

Etcd 對外提供服務的伺服器證書及私鑰，比如 etcd-ctl 存取 Etcd 的時候就會用 ca.crt 去驗證 server.crt

Etcd 啟動時通過 - --cert-file=/etc/kubernetes/pki/etcd/server.crt，- --key-file=/etc/kubernetes/pki/etcd/server.key 來設定伺服器端證書可私鑰

server.crt  server.key

Etcd node 間證書

Etcd 節點之間相互進行認證的 peer 證書、私鑰，結點之間心跳檢測，資料同步等通訊都會使用 peer.crt 來驗證

通過 - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt，- --peer-key-file=/etc/kubernetes/pki/etcd/peer.key 來設定

peer.crt  peer.key

Etcd 健康檢查使用者端證書

探測 Etcd 服務健康檢查介面，使用者端會下載伺服器端證書進行驗證，伺服器端也會下載使用者端證書驗證，即下面的使用者端證書，這個需要使用者端來設定

healthcheck-client.crt  healthcheck-client.key

Kube-apiserver

Kube-apiserver 證書位於 /etc/kubernetes/pki ，同樣我們通過 Kube-apiserver 的 static-pod yaml 檔案來一一解釋下每個證書的作用。

  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.0.4.3
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --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-key-file=/etc/kubernetes/pki/sa.pub
    - --service-cluster-ip-range=10.96.0.0/12
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    image: k8s.gcr.io/kube-apiserver:v1.15.2

Kube-apiserver 根證書

用來簽發 Kubernetes 中其他證書的 CA 證書及私鑰，Kube-apiserver 會設定自己的根證書，也會設定 etcd 的根證書，是因為 Kube-apiserver 會作為使用者端去存取 Kubelet，需要 ca.crt 來驗證 Kubelet 的伺服器端證書，而且 Kube-apiserver 也會作為使用者端去存取 Etcd，因為 Etcd 與 Kubernetes 不同屬一個根證書，所以設定兩個不同 CA。

通過 - --client-ca-file=/etc/kubernetes/pki/ca.crt，- --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt 分別設定

ca.crt  ca.key

Kube-apiserver 伺服器端證書

Kube-apiserver 對外提供服務的證書及私鑰，通過 --tls-cert-file=/etc/kubernetes/pki/apiserver.crt，--tls-private-key-file=/etc/kubernetes/pki/apiserver.key 設定

apiserver.crt   apiserver.key

假如 Kube-apiserver 自定義對外存取時，要在伺服器端證書的 SANs（Subject Alternative Name) 欄位中新增對應的 DNS名稱 或 IP地址，否則使用者端會因存取地址與證書不匹配而報錯。kubeadm 會幫我們設定一些預設的 SANs，包括 master 結點 IP，Kube-apiserver SVC IP 等。可以通過 openssl 命令檢視證書的 SANs

$ openssl x509 -noout -text -in /etc/kubernetes/pki/apiserver.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1302536908518083956 (0x12138a6acb0e4d74)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: May 10 06:48:30 2023 GMT
            Not After : Apr 16 06:48:32 2123 GMT
        Subject: CN=kube-apiserver
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d8:c6:9c:82:2c:92:53:5b:68:34:ac:09:4a:2c:
                    3c:1f:8b:e9:bd:be:bb:61:cf:96:f6:e8:5d:60:da:
                    4f:ea:38:c4:81:6a:bf:33:6f:d7:42:1f:9e:02:09:
                    51:f6:bc:9d:8f:56:9a:aa:fd:d7:b1:41:20:1e:cd:
                    69:6c:1e:04:d3:5f:6a:cd:3a:84:9b:51:a5:c5:79:
                    9c:8b:d8:b0:a0:fb:7e:3c:b6:b0:47:a7:56:d9:bf:
                    cd:76:40:e5:5f:08:a0:e1:50:dd:89:8a:76:2b:fc:
                    46:8b:53:fb:92:a1:ab:35:01:fe:11:8b:5b:d2:9a:
                    c8:41:4a:1f:6f:09:04:24:a1:44:bd:d2:73:97:75:
                    d7:25:9a:18:cf:a0:42:8b:22:9b:0e:c4:98:09:c2:
                    95:11:30:56:30:4e:7c:cb:47:18:9b:4e:f4:3d:5f:
                    cd:c2:f1:ca:f5:f2:02:78:9a:26:c8:cd:97:d4:30:
                    da:07:97:33:9e:63:54:5f:a4:3a:e9:82:00:f2:53:
                    2a:bc:98:b6:bc:ba:22:9a:c9:22:34:2e:86:cd:4f:
                    9a:e7:7a:1d:e4:5f:d8:8a:2e:28:12:01:d3:40:5e:
                    63:37:ba:46:c4:e2:1d:be:20:52:fd:69:37:75:79:
                    1b:69:e6:20:d7:c8:43:bf:09:3f:27:0d:f8:5e:95:
                    fd:db
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Authority Key Identifier: 
                keyid:8B:81:2B:52:44:15:2A:D0:CF:96:FE:FD:40:14:E8:C0:56:8E:83:9E
						**# 這裡**
            X509v3 Subject Alternative Name: 
                DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:apiserver.cluster.local, DNS:kubernetes.default.svc.cluster.local, DNS:master-172-31-97-104, DNS:localhost, DNS:kubernetes, IP Address:127.0.0.1, IP Address:10.233.0.1, IP Address:10.103.97.2, IP Address:172.31.97.104
    Signature Algorithm: sha256WithRSAEncryption
         c2:c4:a4:48:1c:78:32:3c:04:37:79:f0:87:7e:92:ac:14:64:
         ef:84:28:d2:f7:c0:62:75:c3:bf:cf:ec:f7:c2:8f:2f:91:3e:
         b0:99:f1:6c:7f:98:62:4b:82:a5:d6:e5:d0:4a:cb:16:b2:8d:
         d6:95:89:ff:50:15:01:0f:29:13:49:c7:8c:69:c4:50:9a:5d:
         7c:fc:b1:8a:30:02:10:2e:c1:cf:b5:37:65:a3:5c:e6:50:ee:
         b0:60:a6:77:6e:3b:98:b7:2d:c2:4c:e3:2d:8f:9e:9f:25:b1:
         32:97:e7:08:d9:cd:cb:69:29:5f:30:08:b3:37:23:25:1d:6a:
         b7:41:20:10:30:44:df:e3:7a:0f:f9:6f:a0:e8:7f:0d:6a:d0:
         89:80:cb:99:a1:32:b9:ca:84:a5:1d:95:91:c5:a6:17:c8:87:
         88:3e:44:b6:5b:d9:21:09:7d:13:68:42:43:2e:33:4d:49:d4:
         c7:0c:38:55:b7:96:d5:27:3d:71:dd:f5:73:de:d9:bd:f9:6b:
         5c:9b:42:c9:18:2c:f9:29:37:87:cc:58:12:24:66:b8:58:31:
         d3:5b:1a:08:a0:f6:b7:ea:f9:49:31:12:a2:aa:8e:6c:3a:56:
         5c:c4:2c:d9:91:32:d3:3a:7d:5e:8c:d5:85:4c:d7:49:71:8b:
         53:26:1b:71

可以看到在 Subject Alternative Name 欄位中，已經包含了一些預設的 Kube-apiserver 存取 DNS 或者 IP。

Tips： 當我們使用 kubeadm 建立叢集時候，可以在init時使用 --apiserver-cert-extra-sans 引數指定 SANs，kubeadm 會在生成證書時在預設的基礎上增加設定的 SANs。

Kube-apiserver 存取 Etcd 的使用者端證書

前面說過 Kubernetest 元件間存取都是採用雙向 TLS 認證，所以 Kube-apiserver 存取 Etcd 的時候，Kube-apiserver 回去校驗 Etcd 伺服器端證書，同時 Etcd 也會校驗 Kube-apiserver 的使用者端證書，達到雙向認證。因為 Etcd 伺服器端證書是有 Etcd 的根證書籤發，所以 Kube-apiserver 需要設定該 CA，通過 --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt 設定。Etcd 校驗 Kube-apiserver 的使用者端證書時，Kube-apiserver 會把該證書傳送給 Etcd，通過 --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt，--etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key 設定。

apiserver-etcd-client.key   apiserver-etcd-client.crt

Kube-apiserver 存取 Kubelet 的使用者端證書

Kube-apiserver 也會去存取 Kubelet，例如 kubectl 檢視 pod 紀錄檔，或者進入 pod 內部。和存取 Etcd 一樣，Kube-apiserver 存取 Kubelet 也是雙向 TLS 認證，Kube-apiserver 校驗 Kubelet 的伺服器端證書，通過 --client-ca-file=/etc/kubernetes/pki/ca.crt，Kubelet 校驗 Kube-apiserver 通過 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt，--kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key。

apiserver-kubelet-client.crt  apiserver-kubelet-client.key

聚合層證書

要擴充套件 Kube-apiserver 的 API 時，可以採用 Kube-apiserver 聚合功能，具體 Kube-apiserver 聚合原理參考 https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/

這裡簡單說明下請求鏈路，當使用 kubectl 對擴充套件 API 發起請求時，首先 Kube-apiserver 收到請求對 kubectl 使用的 Kube-config 進行認證、鑑權，通過後將請求轉發給 APIAggregator，APIAggregator 可以理解為一層代理，然後 APIAggregator 根據 API 的 GroupVersion 來將請求轉發給擴充套件 apiserver，所以 APIAggregator 與開發者開發的擴充套件 apiserver 就需要進行 TLS 認證。

理想情況擴充套件 apiserver 需要自己簽發 CA，然後使用該 CA 簽發伺服器端證書，伺服器端證書由擴充套件 apiserver 程式使用，CA 通過 APIService 資源來發佈告知 Kube-apiserver APIAggregator ，然後 APIAggregator 存取時獲取 APIService 的 caBundle 欄位來認證擴充套件 apiserver。--requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt 來校驗，同時擴充套件 apiserver 也會校驗 APIAggregator 的使用者端證書，APIAggregator 的使用者端證書通過 --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt，--proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key 設定，擴充套件 apiserver 會通過 kube-system 名稱空間下的 extension-apiserver-authentication configmap 獲取簽發 front-proxy-client.crt 的 CA，即 --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt ，Kube-apiserver 啟動時會將該 CA 資訊寫入 extension-apiserver-authentication configmap 中。這樣就達到雙向 TLS 認證的效果。但是擴充套件 apiserver 也可以關閉伺服器端校驗，通過 APIservice 的設定 insecureSkipTLSVerify: true ，這樣就只會擴充套件 apiserver 校驗 APIAggregator 了。

front-proxy-ca.crt  front-proxy-client.crt  front-proxy-ca.key   front-proxy-client.key

上面所說的證書都在 /etc/kubernetes/pki 目錄下，除了 sa.pub 和 sa.key，這個下文講解。在 Kubernetes 叢集中，Kube-controller-manager 和 Kube-scheduler，Kubelet，Kubectl 都是通過 KubeConfig 來存取 Kube-apiserver，原理上都是證書，下面詳細講解下。

Kube-controller-mananger

還是和之前一樣，我們通過 kube-controller-mananger 的 yaml 檔案設定來看看是如何存取 Kube-apiserver。

spec:
  containers:
  - command:
    - kube-controller-manager
    - --allocate-node-cidrs=true
    - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --bind-address=127.0.0.1
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --cluster-cidr=10.244.0.0/16
    - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
    - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
    - --controllers=*,bootstrapsigner,tokencleaner
    - --kubeconfig=/etc/kubernetes/controller-manager.conf
    - --leader-elect=true
    - --node-cidr-mask-size=24
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --root-ca-file=/etc/kubernetes/pki/ca.crt
    - --service-account-private-key-file=/etc/kubernetes/pki/sa.key
    - --use-service-account-credentials=true
    image: k8s.gcr.io/kube-controller-manager:v1.15.2

你會發現在 yaml 中設定了 /etc/kubernetes/controller-manager.conf 這個組態檔，而不是設定 controller-manager 的使用者端證書之類的。Kubernetes 這裡的設計是這樣的，kube-controller-mananger、kube-scheduler、kubelet 等元件，採用一個kubeconfig 檔案中設定的資訊來存取 Kube-apiserver。該檔案中包含了 Kube-apiserver 的地址，驗證 Kube-apiserver 伺服器證書的 CA 證書，自己的使用者端證書和私鑰等存取資訊，這樣元件只需要設定這個 Kubeconfig 就行。

下面我們看看 controller-manager.conf 這個檔案設定的證書和祕鑰是什麼。

$ cat controller-manager.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01EZ3lNREF5TXpBd05Wb1hEVE13TURneE9EQXlNekF3TlZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSndoCmw4ZVd5SlBsSWpwajlTN09VSWRSTWVxV0Mwb2crN3hQemJQZDhzS2NTemZqWjdHc0ttUXlvQjhoQnNlaVVDdUwKai9teVl5Tk02MkxIa0ZKbDI3MXNFWVdmOEtiWS81Y210UmFjRnlMOEpyaTNLQi91eHZnZlEvMXhMK2c3UmRBcQpGQllWRzNtaSs1T1orTExyZlVMUU5qemtoTVllaEhDdHNDRmZJMGF5amJpYk1UUGJLT3lobjV3cHVMZzgvOVdlClNTSnI1TmtnK2R0WHJSZ05YelNpc1JMQVF5MmdEczdOaTN0SklaNjRuRGdIakpyS21HR2dqbEljN1RFdGFUdWcKcnltKy92akVZZ2NxTlhHakY2ekJlT1FXNW5NdUh0K1plYXphZ1QyQTNkUDhGY3lEWVZrSFJVd0RESDBZOVZlcwpOUFAyZnhURzVVZlhWOUV0WVJNQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFEajZLYXVQR2dvVnlGQmdNUzFZYlVFRXFHQmoKN3IwaG5vclNuOVp4dlxZkM1UkZ0UEd0OEI0YU40T3RMa1REUno5ZmdFc1ZidFdoMXRXWURIWUF6N2FDYkVZawpMRTArRzZQMkpxR043SHlrd05BZFp1QS96emhOdVFKZnhjZG5qVHlIRWZXZyt5OEd1S2JqSU1QdFJVOU45bFpoCkZTeUxsYjNvektYbURDK2RuSHhHMXhNbnpCM05TQStYeGk3ZDVHakExemUzYXFxZXM2bWVONTNYWnFkeDE2N0gKLzNBNld6NjZ4UE9nOHlsUFNVa3R5bU1HNTFkOTFsdTFiZWJYUExtdmc0K3BBeFdhZGJGZ21MR0Z0UE1URXcrWgpIRHZzK3E2NDBIOWJpeitPV2Rld0hjUXE0TW9oQ1dubDhhVzVJYWVSYW1mWS9zZy8xd1NXMkZteGViQT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    server: https://10.0.4.3:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: system:kube-controller-manager
  name: system:kube-controller-manager@kubernetes
current-context: system:kube-controller-manager@kubernetes
kind: Config
preferences: {}
users:
- name: system:kube-controller-manager
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lJSWN4Ynk4VWEvV1F3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TURBNE1qQXdNak13TURWYUZ3MHlNVEE0TWpBd01qTXdNRGRhTUNreApKekFsQmdOVkJBTVRIbk41YzNSbGJUcHJkV0psTFdOdmJuUnliMnhzWlhJdGJXRnVZV2RsY2pDQ0FTSXdEUVlKCktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQU5YK0Vqa3c0NDNTNzh5d05LL0dIQTV2eFZCS0Rhbi8KZ21yaUlFTW1hYWhlbDllREJXR0s0dVVtY1VXMXU1TCszeUR0amJlKy83MHZ2M3hvSWY1VkNZQXZqYUorN2twUQpyYW5RUE93cFJnbUlqNTEzV1FsZzMxWDlqREpuNlAybVpYTmZ6YWVOalBwOXdrZGkzZGVqSUZaSm1zYjQ0R3VwCkNrdlpodE5iYUlrVVU1U3dCT3h1dE92Um1uemdHQ3BQa0c4ME9pNWdYcDVzTHJ2dmVYSWxpem5wbHNsa3pxbjQKdWNJMHZMekhQY0JsSWhncEVJOXdCVTFOK3VWLzIxTmRaT3p1UlpFVFRMQ0xmNjhVR0FlM0ZCVXJHblJCUTJJZgpKLzhpNnJVQ2l1T25PQWUvOFNLbzlVM0ExOHN3RDJYandTZVo1NzRRclRGdkFjUjBYQ1BibW4wQ0F3RUFBYU1uCk1DVXdEZ1lEVlIwUEFRSC9CQVFEQWdXZ01CTUdBMVVkSlFRTU1Bb0dDQ3NHQVFVRkJ3TUNNQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFBcTY0cVBnVllzRzFGb05QQTRTNlJ0bGwrbUdTVUE2QlVNakQrWkt0eVM1NExCVFZnWQp5K1IrL0Zpd3o2RW1xWUpnZ0EyNWZGdkszSWlGNCt5d3JxeDZETlVZa3BBQkZFWXQ5VjU4a2gxV0pha3BvMEZQCnRZRkFaNmlEMlg4UlBZeUUwSXBMYlFqTGRncS9LYTRiSlhZRFhsS3RTV2UwbmJoY2FUWjRpRm5BcldndmpRQ0sKU05kV0tmSUpGNjJiWGE5a1BGc3ROYWVrWjdoQVZEZzhBbEd1c0tlYVFLdFNLZ2dMREFreElRWjlnNTZSVUprYwp6UUhRVHlibmVTcXJEN3cxT0xIR2RpYmZEYXhzMWdtbi9oL20xNk5ib3NMUlgxNkkxK3VKOWV1d29TWlp3Z29zCmpVRExuWVg1Zm1ZcEdhK2ZDbjdiMTJ4Mzg3SFpmbkE4eTFDTQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBMWY0U09URGpqZEx2ekxBMHI4WWNEbS9GVUVvTnFmK0NhdUlnUXlacHFGNlgxNE1GCllZcmk1U1p4UmJXN2t2N2ZJTzJOdDc3L3ZTKy9mR2doL2xVSmdDK05vbjd1U2xDdHFkQTg3Q2xHQ1lpUG5YZFoKQ1dEZlZmMk1NbWZvL2FabGMxL05wNDJNK24zQ1IyTGQxNk1nVmttYXh2amdhNmtLUzltRzAxdG9pUlJUbExBRQo3RzYwNjlHYWZPQVlLaytRYnpRNkxtQmVubXd1dSs5NWNpV0xPZW1XeVdUT3FmaTV3alM4dk1jOXdHVWlHQ2tRCmozQUZUVTM2NVgvYlUxMWs3TzVGa1JOTXNJdC9yeFFZQjdjVUZTc2FkRUZEWWg4bi95THF0UUtLNDZjNEI3L3gKSXFqMVRjRFh5ekFQWmVQQko1bm52aEN0TVc4QnhIUmNJOXVhZlFJREFRQUJBb0lCQURCTHVrTXNGSDlpdHZwRQpYbSs1VDRXMmxocXJ5Kyt0R2ZzVGMrS1QzYzdCSXBYaUhTbkpsYkhQL2txVVhIUXRqNkEzM1A4MlhUT09maklPCnNuVmJMZHkvWHNEbzB0RDA2bXpqOFl2L09LNVlJc21RTVFrYjB1dnVZR0RUOE5LbVpra211eHh3cHZ1MXZFNHUKTXhGQzRMNTR1RFRsNElpTHl5WVpQd09lb3JZazlYVi9LSkN4a2g1RnVmZzBublI5MjNXQ1lDZVNyaUVWRm9LbQovbzBKYmlVNE1MU3FxallRWnljRnFSbGM0Vy9sMVJuMldLbU1KZ29EVUE4eEZiOEtJYjk4bGpOR0F0Z2QyNFQwCmcxS1VnbDRNazlPOTEvUzdrbHc3L3dsaHBkY3g0eFJ2dEtBTWZiM0RBa1V4MmpFZDB2ckZvU3NseHM0NXJOc2QKM296ZDhFRUNnWUVBM1p2OGJZTDE0ZlU3c0ZnVXlXekl4ejA3WlJ5czFzZitESmVXRmNCOEZoa2Jpb3Q1T0dqZwp0RHZmQlcvOXliMmtPM3RRNlJxNkFMOFpKcGE1QjcyOVF2YUJ1bDlpRHladVZndC8xUnY1d290Smo1SGZQS25vCnFVNzh6NVdtQUR2VitmQTVXaW9ad0hBVzQ3RHFLUU5OdzYyNWZaZFV3NTFXblZOWHpBZWR2VkVDZ1lFQTl6TjgKU3JrOXlsUlBaZnQ4emgrK05OZndoOFgzRWlZR2JwUHNpWG4zTitxYnQ4eXJORFhNYXRId1NrS2dxWDdxU0twQQpDc3ZGeXRreDhBc2VMaDZhQzBMbXh1aVVtQW8yMnBBU21veDY3VFo1ditqeXdtNGt3TFFXdjh6R0ptMjhyUlRVClZkejMvZC9pTkJHZDlKaHB0dzY3REUvcENPTm9vVWhOOHFwbVQyMENnWUJSYm9vNWE1QVNzZHgzRmthOUpWNDUKNkVRMUNXNXhsaGZDWk1sZndOVllBVzNmWVJUd0o0bTZjTzJvdjloUUU0R1A0ZVovWWJUTHBXMEdnd2dHMGpBRAp0VFZDV041ZGxzK2dpcVUwbUEwVThiM2NKY3dVTEpNejg3UnVTeDB1cE00aUE2WHZmZHpzbThPdGMwcjRPeUNPCk1QNGlLa09aaGUxWDdsSXF4UG12b1FLQmdFdk45UUp4RmJxeTZmb3JDWlduOUVyK0lSdHhvSmRuSTdmTEV0RUIKbnNiOTRheVdUYlhmL1lTUVJuQnZTQmRSL1FRMWVSZ1didHdLaUo3RXVnZUlpTktGUElHb2x0Q2M2VDlTeVBHdAp2SkI3a1JCQm5oZnpjTC9MT2VLdEorSm02bUhsTGt2NlMrNEZOcmVpNDE0N1VzZTQ4N0VOM0RkR2pUSlFHdDhjClUrMXRBb0dCQU1JVzFrcHhGZ1NOUjJORGczdHlJWGNhVDJiQStPTWZrc25nNVdrQUdqb0xveS9laE5waWtJTHAKbHFVVG5oZENaMHBvV3d2MUkxdkZ5VVRJTTREUHd1WVNicnZQNjV2UkJua1M5RGlldVE5Q0FEbXRkT0h1WWR2VgpzSy90cmQ5RTNTdUNVNWNSdXJqVkFacGJoOVNIQzU3bk9rVTRJY2EzT0EvbGZsSmRvbUl0Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

我們解析下 certificate-authority-data 這個內容看看是不是 Kubernetes 的 CA 的證書

$ echo "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01EZ3lNREF5TXpBd05Wb1hEVE13TURneE9EQXlNekF3TlZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSndoCmw4ZVd5SlBsSWpwajlTN09VSWRSTWVxV0Mwb2crN3hQemJQZDhzS2NTemZqWjdHc0ttUXlvQjhoQnNlaVVDdUwKai9teVl5Tk02MkxIa0ZKbDI3MXNFWVdmOEtiWS81Y210UmFjRnlMOEpyaTNLQi91eHZnZlEvMXhMK2c3UmRBcQpGQllWRzNtaSs1T1orTExyZlVMUU5qemtoTVllaEhDdHNDRmZJMGF5amJpYk1UUGJLT3lobjV3cHVMZzgvOVdlClNTSnI1TmtnK2R0WHJSZ05YelNpc1JMQVF5MmdEczdOaTN0SklaNjRuRGdIakpyS21HR2dqbEljN1RFdGFUdWcKcnltKy92akVZZ2NxTlhHakY2ekJlT1FXNW5NdUh0K1plYXphZ1QyQTNkUDhGY3lEWVZrSFJVd0RESDBZOVZlcwpOUFAyZnhURzVVZlhWOUV0WVJNQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFEajZLYXVQR2dvVnlGQmdNUzFZYlVFRXFHQmoKN3IwaG5vclNuOVp4dlUxZkM1UkZ0UEd0OEI0YU40T3RMa1REUno5ZmdFc1ZidFdoMXRXWURIWUF6N2FDYkVZawpMRTArRzZQMkpxR043SHlrd05BZFp1QS96emhOdVFKZnhjZG5qVHlIRWZXZyt5OEd1S2JqSU1QdFJVOU45bFpoCkZTeUxsYjNvektYbURDK2RuSHhHMXhNbnpCM05TQStYeGk3ZDVHakExemUzYXFxZXM2bWVONTNYWnFkeDE2N0gKLzNBNld6NjZ4UE9nOHlsUFNVa3R5bU1HNTFkOTFsdTFiZWJYUExtdmc0K3BBeFdhZGJGZ21MR0Z0UE1URXcrWgpIRHZzK3E2NDBIOWJpeitPV2Rld0hjUXE0TW9oQ1dubDhhVzVJYWVSYW1mWS9zZy8xd1NXMkZteGViQT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="|base64 -d
-----BEGIN CERTIFICATE-----
MIICyDCCAbCgAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
cm5ldGVzMB4XDTIwMDgyMDAyMzAwNVoXDTMwMDgxODAyMzAwNVowFTETMBEGA1UE
AxMKa3ViZXJuZXRlczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJwh
l8eWyJPlIjpj9S7OUIdRMeqWC0og+7xPzbPd8sKcSzfjZ7GsKmQyoB8hBseiUCuL
j/myYyNM62LHkFJl271sEYWf8KbY/5cmtRacFyL8Jri3KB/uxvgfQ/1xL+g7RdAq
FBYVG3mi+5OZ+LLrfULQNjzkhMYehHCtsCFfI0ayjbibMTPbKOyhn5wpuLg8/9We
SSJr5Nkg+dtXrRgNXzSisRLAQy2gDs7Ni3tJIZ64nDgHjJrKmGGgjlIc7TEtaTug
rym+/vjEYgcqNXGjF6zBeOQW5nMuHt+ZeazagT2A3dP8FcyDYVkHRUwDDH0Y9Ves
NPP2fxTG5UfXV9EtYRMCAwEAAaMjMCEwDgYDVR0PAQH/BAQDAgKkMA8GA1UdEwEB
/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBADj6KauPGgoVyFBgMS1YbUEEqGBj
7r0hnorSn9ZxvU1fC5RFtPGt8B4aN4OtLkTDRz9fgEsVbtWh1tWYDHYAz7aCbEYk
LE0+G6P2JqGN7HykwNAdZuA/zzhNuQJfxcdnjTyHEfWg+y8GuKbjIMPtRU9N9lZh
FSyLlb3ozKXmDC+dnHxG1xMnzB3NSA+Xxi7d5GjA1ze3aqqes6meN53XZqdx167H
/3A6Wz66xPOg8ylPSUktymMG51d91lu1bebXPLmvg4+pAxWadbFgmLGFtPMTEw+Z
HDvs+q640H9biz+OWdewHcQq4MohCWnl8aW5IaeRamfY/sg/1wSW2FmxebA=
-----END CERTIFICATE-----
// 檢視叢集 ca
$ cat pki/ca.crt
-----BEGIN CERTIFICATE-----
MIICyDCCAbCgAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
cm5ldGVzMB4XDTIwMDgyMDAyMzAwNVoXDTMwMDgxODAyMzAwNVowFTETMBEGA1UE
AxMKa3ViZXJuZXRlczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJwh
l8eWyJPlIjpj9S7OUIdRMeqWC0og+7xPzbPd8sKcSzfjZ7GsKmQyoB8hBseiUCuL
j/myYyNM62LHkFJl271sEYWf8KbY/5cmtRacFyL8Jri3KB/uxvgfQ/1xL+g7RdAq
FBYVG3mi+5OZ+LLrfULQNjzkhMYehHCtsCFfI0ayjbibMTPbKOyhn5wpuLg8/9We
SSJr5Nkg+dtXrRgNXzSisRLAQy2gDs7Ni3tJIZ64nDgHjJrKmGGgjlIc7TEtaTug
rym+/vjEYgcqNXGjF6zBeOQW5nMuHt+ZeazagT2A3dP8FcyDYVkHRUwDDH0Y9Ves
NPP2fxTG5UfXV9EtYRMCAwEAAaMjMCEwDgYDVR0PAQH/BAQDAgKkMA8GA1UdEwEB
/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBADj6KauPGgoVyFBgMS1YbUEEqGBj
7r0hnorSn9ZxvU1fC5RFtPGt8B4aN4OtLkTDRz9fgEsVbtWh1tWYDHYAz7aCbEYk
LE0+G6P2JqGN7HykwNAdZuA/zzhNuQJfxcdnjTyHEfWg+y8GuKbjIMPtRU9N9lZh
FSyLlb3ozKXmDC+dnHxG1xMnzB3NSA+Xxi7d5GjA1ze3aqqes6meN53XZqdx167H
/3A6Wz66xPOg8ylPSUktymMG51d91lu1bebXPLmvg4+pAxWadbFgmLGFtPMTEw+Z
HDvs+q640H9biz+OWdewHcQq4MohCWnl8aW5IaeRamfY/sg/1wSW2FmxebA=
-----END CERTIFICATE-----

從解碼可以發現，Kubeconfig 設定的就是 Kubernetes 的 CA 證書，client-certificate-data 和 client-key-data 就是 Kube-controller-manager 用來存取 Kube-apiserver 的使用者端證書和祕鑰，只不過 Kubeconfig 對內容進行了 base64 編碼。這個就是整個 Kube-controller-manager和 Kube-apiserver 證書認證的方式。

Kube-scheduler

Kube-scheduler 也是同樣的原理，也是在 yaml 中設定一個 Kubeconfig 來進行存取 Kube-apiserver

$ cat scheduler.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01EZ3lNREF5TXpBd05Wb1hEVE13TURneE9EQXlNekF3TlZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSndoCmw4ZVd5SlBsSWpwajlTN09VSWRSTWVxV0Mwb2crN3hQemJQZDhzS2NTemZqWjdHc0ttUXlvQjhoQnNlaVVDdUwKai9teVl5Tk02MkxIa0ZKbDI3MXNFWVdmOEtiWS81Y210UmFjRnlMOEpyaTNLQi91eHZnZlEvMXhMK2c3UmRBcQpGQllWRzNtaSs1T1orTExyZlVMUU5qemtoTVllaEhDdHNDRmZJMGF5amJpYk1UUGJLT3lobjV3cHVMZzgvOVdlClNTSnI1TmtnK2R0WHJSZ05YelNpc1JMQVF5MmdEczdOaTN0SklaNjRuRGdIakpyS21HR2dqbEljN1RFdGFUdWcKcnltKy92akVZZ2NxTlhHakY2ekJlT1FXNW5NdUh0K1plYXphZ1QyQTNkUDhGY3lEWVZrSFJVd0RESDBZOVZlcwpOUFAyZnhURzVVZlhWOUV0WVJNQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFEajZLYXVQR2dvVnlGQmdNUzFZYlVFRXFHQmoKN3IwaG5vclNuOVp4dlUxZkM1UkZ0UEd0OEI0YU40T3RMa1REUno5ZmdFc1ZidFdoMXRXWURIWUF6N2FDYkVZawpMRTArRzZQMkpxR043SHlrd05BZFp1QS96emhOdVFKZnhjZG5qVHlIRWZXZyt5OEd1S2JqSU1QdFJVOU45bFpoCkZTeUxsYjNvektYbURDK2RuSHhHMXhNbnpCM05TQStYeGk3ZDVHakExemUzYXFxZXM2bWVONTNYWnFkeDE2N0gKLzNBNld6NjZ4UE9nOHlsUFNVa3R5bU1HNTFkOTFsdTFiZWJYUExtdmc0K3BBeFdhZGJGZ21MR0Z0UE1URXcrWgpIRHZzK3E2NDBIOWJpeitPV2Rld0hjUXE0TW9oQ1dubDhhVzVJYWVSYW1mWS9zZy8xd1NXMkZteGViQT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    server: https://10.0.4.3:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: system:kube-scheduler
  name: system:kube-scheduler@kubernetes
current-context: system:kube-scheduler@kubernetes
kind: Config
preferences: {}
users:
- name: system:kube-scheduler
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMzakNDQWNhZ0F3SUJBZ0lJVlUybER1V2Y1OHd3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TURBNE1qQXdNak13TURWYUZ3MHlNVEE0TWpBd01qTXdNRGhhTUNBeApIakFjQmdOVkJBTVRGWE41YzNSbGJUcHJkV0psTFhOamFHVmtkV3hsY2pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCCkJRQURnZ0VQQURDQ0FRb0NnZ0VCQU14SzJrNmZnWG50cHVNM2JPZ2ZUS0V4aVhsdzdMQVc2VHpUK2thcndVS2UKK2hKSExWSjF4OUphazlDajZ2VWRZdEdkRzMyd0V1R0VFa3ltN0dFZXlyeHJneGRsU3NyVmRqQkFTYnhwNndpZApvZ3dmL2xVa2kza2FPVUozVXd6bmFnWCt6ZUh1d2hVN0R3NkNuaUpkMy9SZW9hU0FjZitvbDl0TTRiazRldVRrCnRXaUE5SDk0VnlQam42SUpkUDdNb1h4TWpZN1c1UysxNy9aczBwbXJabHhuWFdqZjZESXdyNnplbStSNlF1YnAKeE5adEk1WWdsNDk2a09BaTZMVW5xemhCNHIzaDdDOUd0SjFnVDk1YmxiQ0VZNzRtNmVLREZpNXFwZ3JRZnA0YwoxMlhRYzNtcGQzY2IrZXlGUFNsYUVDUmRwS1BKazRpZXgxNnN4TmwzRmk4Q0F3RUFBYU1uTUNVd0RnWURWUjBQCkFRSC9CQVFEQWdXZ01CTUdBMVVkSlFRTU1Bb0dDQ3NHQVFVRkJ3TUNNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUIKQVFBWFovVTcxSnRqQXQ3MjJLeVl6Q1RDZlF1bHdMM2EySGN6NGw5NXVaMFNWVG5ncTNhWUJxeVdwQ2puM3VNaApTaGN5OUZ4ZC92am52YXVTWUdXY05abm84dEVNUFhTaitNNzI5bW1vTUNUa0xCUGJSVGZwRGt3aDNnRS9IRWtuCnN0emRoZTZ3dWp4OWduMXl5WTJSOTFTZ3U3cjdwZjlLM1hOeFh2SFo3Z0tDQnJIVisyMVlQTkNCaC8rYlVuZkcKY2pvNlNNZHphT0Y5SlJod2pUS0l5VTlkeXJkbFBLUlR0Q3NGVEttdy9HM1d4Z1gvbGRCZnNsZmNaVXR4TlpsYQpablBVNlYvK3gwelBTVG56RzRmYTQ3UkhlZmc3YzczQkZjL0ZiYW9obmhrZHNPMVBNWGdhSjQ1bGo1NVNPL1phCmlIbUphZUF3bnh5d0hMazFtclE1b0ttVAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBekVyYVRwK0JlZTJtNHpkczZCOU1vVEdKZVhEc3NCYnBQTlA2UnF2QlFwNzZFa2N0ClVuWEgwbHFUMEtQcTlSMWkwWjBiZmJBUzRZUVNUS2JzWVI3S3ZHdURGMlZLeXRWMk1FQkp2R25yQ0oyaURCLysKVlNTTGVSbzVRbmRURE9kcUJmN040ZTdDRlRzUERvS2VJbDNmOUY2aHBJQngvNmlYMjB6aHVUaDY1T1MxYUlEMApmM2hYSStPZm9nbDAvc3loZkV5Tmp0YmxMN1h2OW16U21hdG1YR2RkYU4vb01qQ3ZyTjZiNUhwQzV1bkUxbTBqCmxpQ1hqM3FRNENMb3RTZXJPRUhpdmVIc0wwYTBuV0JQM2x1VnNJUmp2aWJwNG9NV0xtcW1DdEIrbmh6WFpkQnoKZWFsM2R4djU3SVU5S1ZvUUpGMmtvOG1UaUo3SFhxekUyWGNXTHdJREFRQUJBb0lCQVFDbmJhVlRFSGlkdy82bApjMVJIUFBlaG1DYXlKN0ZqYzdOOWpjRXRVREJZZUZBODBLYTlVUmdPTnZ1ejM5TjlSYk1xVlpjbFFEdUpKYU9WCnZLdzN3SE9wVG5lbW9mWlZHL0w4QW9RcjdhYVpiZzlUM3BpamtRclptbnRaRk5BMDRDZk5lQkdsMi9hbVRidSsKU2FCdVMvOXltR2ZqbVAxVTZRaGp5N09uQ0RuNEFsMmw1SXJpUCtlSTgxS3ZjVjRWUWNhcmtQL0F5SityQm56SgpSZjNRSFBRL2pFaUVRMm9kKzQ4N1FzSWNZVlcwZ0FmQ3pKN05NMUJMeTE0Yy8zUFJRS3JLZTdXT3AwM2Z3QmkxCk5TRlc1dmxSUkpnTDduSHQ4TkdsSUhHRE5VT29KR0UvVnppekJUVFpQRS9nOEkxZ1FLYko5b3ZSdXJQa0J6VGsKRHNGQ281bEJBb0dCQU5qalNTVXIybFo0Z1B6MEZ6bnBMTEFBaVhBSDkwZFlBb1BQSUhoWDR2WmtRUjE4Ykx2NgoraXVSR2dMTkQyckV4dHk3dE1tcTQrZkt2S1VXRWorOVR0KzNqWTVmTFdCeWhNTk1uaXN2eDFsdkxlZnFybkRvCnlkODdPb0p3TnZZdit2YitQR3NGaU51SHdXUTR4Wit3WTFaYitCUnB5UVJNUEs1TnVEbDRFMXZQQW9HQkFQRWkKRitwS1VJSmE0NGZuWDk3L1lHalh6Z1lWTEQ4RkRRMTh4dmY3TG43UEhUNzJoK1VCaXJFV29uK2RmcDFBZS95UwpTMER6Q2ZLUDdiM0R3YkxPbmRKcHdLWnUrUjdBaEs5RGFlVEJ3Y2FkRDFpTzNoME5RSVFoVFJPaVJRclN4RWpmCllXVnRmUXFuSUJhS3pMSnRCakVtakRDcXJ2QjJ3QTRza1Z5d09WZWhBb0dBTWZWb3k5OG1FL1QrQVVaWWMwWjYKdksvaStLTmRHbG56ZWxranFaVFUrdHh0QTFXOTFpOGhvUmR6WG1ITncxSkFYR2dBWk5Pd1c1d2ZpQWRsZkxrbQppZkhGOFoySzNrU0N3Rm5OdFRUMFBtMlZyVzRwY0dpdTEzVFZMV2Fid21tYTdYbnlnTlJ0aWVQamNDcURteDBPClJMNDZqcmt2VElZakZDTmk1Qm44bTVFQ2dZQmNHdUs1cW1Nd041bGJpd1J5d0dkS0JNeDhSRkFmVGtXYkZrTkYKNjVycDh5Qy9zUmxkWHdaaitEcGZ0bi9yZnZzZEVhQlBFY2FGOFhZbEd3WDh6N0UyOHhBVVFxVkRtdFBUd2xOTApmcnNPcTJWMk5UUWdNclNuQTdWV1A1QlJ2d29jcjc2YktJUXZzb0N1TzV4T3R4ZzdZL2IraStQQWxBdHVIcFh6CnFwaHNvUUtCZ1FERkxITzFwTTNPNlRWN3cybThKWVI0WGxBUWtLZkRPMlFGaDB0bGM1bk1rZUdZbHZFUUlZdVMKS2liV3NJNHVwMHFRcFZjdHF2VU9wc2V1Rk5ZdGVRQzF6YncxNWp4a0xEMm9Gb2c1Yk9WRXk3ekZERU1kVmdpRwpEbjhkbHN3SWp0bUF1SDFGOWdBbGR1V1M0cXkyV0I0SlRPZjBlTDVOM1dTWkRzcm91anA5NlE9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
-24

同理，解析 certificate-authority-data 也是 Kubernates 的 CA 證書，client-certificate-data 和 client-key-data 就是 Kube-scheduler 用來存取Kube-apiserver 的使用者端證書和祕鑰

Kubelet

Kubelet 與 Kube-apiserver 一樣，即可以作為伺服器端，又可以作為使用者端，所以分類講解

Kubelet 使用者端證書

Kubelet 和其他元件類似，用的 Kubeconfig 與 Kube-apiserver 進行認證、鑑權的，都是用 Kubernates 的 CA 簽發。

這邊我們會給每個節點生成一份使用者端的證書和私鑰，直接指向一個 kubelet-client-current.pem 檔案，這裡包含了證書和私鑰，每一個節點都不一樣。因此每個節點都會有一個自己的使用者端證書和私鑰。

$ cat /etc/kubernetes/kubelet.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01EZ3lNREF5TXpBd05Wb1hEVE13TURneE9EQXlNekF3TlZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSndoCmw4ZVd5SlBsSWpwajlTN09VSWRSTWVxV0Mwb2crN3hQemJQZDhzS2NTemZqWjdHc0ttUXlvQjhoQnNlaVVDdUwKai9teVl5Tk02MkxIa0ZKbDI3MXNFWVdmOEtiWS81Y210UmFjRnlMOEpyaTNLQi91eHZnZlEvMXhMK2c3UmRBcQpGQllWRzNtaSs1T1orTExyZlVMUU5qemtoTVllaEhDdHNDRmZJMGF5amJpYk1UUGJLT3lobjV3cHVMZzgvOVdlClNTSnI1TmtnK2R0WHJSZ05YelNpc1JMQVF5MmdEczdOaTN0SklaNjRuRGdIakpyS21HR2dqbEljN1RFdGFUdWcKcnltKy92akVZZ2NxTlhHakY2ekJlT1FXNW5NdUh0K1plYXphZ1QyQTNkUDhGY3lEWVZrSFJVd0RESDBZOVZlcwpOUFAyZnhURzVVZlhWOUV0WVJNQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFEajZLYXVQR2dvVnlGQmdNUzFZYlVFRXFHQmoKN3IwaG5vclNuOVp4dlUxZkM1UkZ0UEd0OEI0YU40T3RMa1REUno5ZmdFc1ZidFdoMXRXWURIWUF6N2FDYkVZawpMRTArRzZQMkpxR043SHlrd05BZFp1QS96emhOdVFKZnhjZG5qVHlIRWZXZyt5OEd1S2JqSU1QdFJVOU45bFpoCkZTeUxsYjNvektYbURDK2RuSHhHMXhNbnpCM05TQStYeGk3ZDVHakExemUzYXFxZXM2bWVONTNYWnFkeDE2N0gKLzNBNld6NjZ4UE9nOHlsUFNVa3R5bU1HNTFkOTFsdTFiZWJYUExtdmc0K3BBeFdhZGJGZ21MR0Z0UE1URXcrWgpIRHZzK3E2NDBIOWJpeitPV2Rld0hjUXE0TW9oQ1dubDhhVzVJYWVSYW1mWS9zZy8xd1NXMkZteGViQT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    server: https://10.0.4.3:6443
  name: default-cluster
contexts:
- context:
    cluster: default-cluster
    namespace: default
    user: default-auth
  name: default-context
current-context: default-context
kind: Config
preferences: {}
users:
- name: default-auth
  user:
    client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
    client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

$ cat /var/lib/kubelet/pki/kubelet-client-current.pem
-----BEGIN CERTIFICATE-----
MIICZzCCAU+gAwIBAgIUPrHB6WlowbhzImI5+NnT0Y4ZzlAwDQYJKoZIhvcNAQEL
BQAwFTETMBEGA1UEAxMKa3ViZXJuZXRlczAeFw0yMDA4MjAwMjI4MDBaFw0yMTA4
MjAwMjI4MDBaMDsxFTATBgNVBAoTDHN5c3RlbTpub2RlczEiMCAGA1UEAxMZc3lz
dGVtOm5vZGU6dm0tNC05LWNlbnRvczBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA
BJ1Qb3DwFRUjIYaaBxNGTieXObGKdGLG8/HVdwXNkVSIWLGBkz9QsFaOh1IsiQ6g
5FfxRBneWhyQTOgMmD0yvymjVDBSMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAK
BggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR2QsIZ/qWdhOExDObO
wiBjcpbUMTANBgkqhkiG9w0BAQsFAAOCAQEATF/xpZD9kcCMFqFDlbo1Zn4DwXh6
X3s5T6r3QNtZQ1SeUHUhnL2Q1DrpICAEFxoqMdB75hxlYCs5UOP6YwBUX77qAVs9
QAXW7/sEhS5firGGP8pEQXgaUWwv6tu2V574JL7M9p+koHL/Fbev9fad8I71XIDQ
qkmnf892VCYnkvw1s7wNJENlxNQUQ1rw0wEccyKlYpxbqXCYStSloSaz6JCFnT06
+EXV5cr/G8UZnYRoMNu6jiajIxhFmYQqBNCqOlJo24TVjeLlNTL5AD8aSXcQ+O16
PWhBYNdEOulokdjg84gAg6jSqN2g+hi4+gHMG1Rw2h+9iu5E5txFjKGiMQ==
-----END CERTIFICATE-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIN75eP2QG76VLv/nRWiLzW9Fg9hCzeb33BrZ5n9PhwhToAoGCCqGSM49
AwEHoUQDQgAEnVBvcPAVFSMhhpoHE0ZOJ5c5sYp0Ysbz8dV3Bc2RVIhYsYGTP1Cw
Vo6HUiyJDqDkV/FEGd5aHJBM6AyYPTK/KQ==
-----END EC PRIVATE KEY-----

Kubelet 使用者端證書可以被自動續簽，上面的證書期限都是固定的，下面具體續簽的原理

CSR(CertificateSigningRequest)

Kubernetes 提供了一套證書相關的 API(Certificate API），用於實現證書的申請與自動簽發。證書的申請者，如 Kubelet，可以通過建立一個 CSR資源來向指定的證書籤名者（由 CSR 的 singerName 欄位指定）申請證書籤名，CSR 請求可能被批准，也可能被拒絕。當 CSR 請求被批准後，對應的證書籤名者才會對證書籤名，並將簽名後的證書儲存在 CSR 的 status.Certificat 欄位中，至此整個簽發流程就完成了。證書的申請者可以從 status.Certificate 中獲取已經簽名的證書。Kube-controller-manager 內建了一些簽名者，分別處理對應 singerName 的 CSR 請求：

  • kubernetes.io/kube-apiserver-client，申請用於存取 Kube-apiserver的證書，不會自動批准。
  • kubernetes.io/kube-apiserver-client-kubelet，Kubelet 申請用於存取 Kube-apiserver的使用者端證書，可能會被自動批准。
  • kubernetes.io/kubelet-serving， Kubelet 的伺服器端證書，不會自動批准。
  • kubernetes.io/legacy-unknown，第三方應用的證書申請，不會自動批准。

Kubelet 進行使用者端證書輪換時，建立的 CSR 中的 singerName 就是 kubernetes.io/kube-apiserver-client-kubelet，正常情況下，會被 Kube-controller-manager 自動批准，然後簽發證書。

當 CSR 提交後，需要由審批者（可以是人，也可以是程式）批准後才能進行後續的證書籤發操作。Kube-controller-manager 內建了一個審批控制器，可以自動批准某些 CSR 請求。但為了防止與其他的審批者發生衝突，Kube-controller-manager 不會顯式的拒絕任何 CSR。對於不會被Kube-controller-manager 處理的 CSR，我們可以使用 API 的方式處理，如實現一個專門的控制器來來自動批准或拒絕，或者使用 Kubectl 命令列：

# 批准一個CSR
$ kubectl certificate approve <certificate-signing-request-name>
# 拒絕一個CSR
$ kubectl certificate deny <certificate-signing-request-name>

Kubelet 使用者端證書自動續簽

對於 kubernetes.io/kube-apiserver-client-kubelet 型別的 CSR，Kube-controller-manager 根據申請者是否具備對應的 RBAC 許可權，來決定是否批准該 CSR。Kubelet 在兩種情況下都會建立 CSR 請求：

1、在首次加入叢集時，還沒有生成使用者端證書，Kubelet 需要建立 CSR 資源來申請，這個階段也就是 TLS 引導階段。

2、當用戶端證書快過期時，Kubelet 會發起證書輪換，建立 CSR 請求申請新的證書。

對於這兩種場景，Kubernetes 提供了兩個預設許可權（ClusterRole）：

1、nodeclient：當節點首次建立證書時，Kubelet 還沒有正式的使用者端證書，處於 TLS 引導階段。此時Kubelet 會使用 bootstrap token 認證方式來請求 Kube-apiserver。kubeadm init建立的 bootstrap token 所屬使用者組為 system:bootstrappers:kubeadm:default-node-token，kubeadm 會負責將 nodeclient 許可權賦予該使用者組。

2、selfnodeclient：當節點請求證書輪換時，Kubelet 已經有一個正式的使用者端證書。Kubelet 的證書屬於 system:nodes 使用者組，kubeadm 會負責將 selfnodeclient 許可權賦予該使用者組。

# 兩個預設許可權
$ kubectl get clusterrole -l kubernetes.io/bootstrapping=rbac-defaults  | grep nodeclient
system:certificates.k8s.io:certificatesigningrequests:nodeclient       2021-09-08T14:59:17Z
system:certificates.k8s.io:certificatesigningrequests:selfnodeclient   2021-09-08T14:59:17Z
# kubeadm會負責將這兩個許可權繫結到對應的使用者組
$ kubectl get clusterrolebinding kubeadm:node-autoapprove-bootstrap kubeadm:node-autoapprove-certificate-rotation  -owide
NAME                                            ROLE                                                                               AGE   USERS   GROUPS                                            SERVICEACCOUNTS
kubeadm:node-autoapprove-bootstrap              ClusterRole/system:certificates.k8s.io:certificatesigningrequests:nodeclient       27d           system:bootstrappers:kubeadm:default-node-token
kubeadm:node-autoapprove-certificate-rotation   ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient   27d           system:nodes

當 CSR 請求被批准後，簽發者才可以簽發證書。Kube-controller-manager 同樣也內建了簽發控制器。通過為 Kube-controller-manager 設定 --cluster-signing-cert-file 和 --cluster-signing-key-file 啟動引數以開啟內建的簽發控制器，這兩個引數分別表示用於簽名的證書和私鑰，也就是叢集的 CA 證書。

在1.18之前，kube-controller-manager會為所有已經批准的CSR簽發證書。1.18之後，kube-controller-manager限制了CSR的singerName，只會為上述的四種指定singerName的CSR請求籤發證書。類似的，對於不會自動簽發證書的CSR請求，我們同樣可以通過kubectl來手動簽發，亦或者通過實現一個專門的控制器來自動簽發。

Kube-controller-manager 通過設定 Kubelet 使用者端證書續簽週期 --experimental-cluster-signing-duration=87600h0m0s，來開啟自動續簽 Kubelet 使用者端證書

Kubelet 的伺服器端證書

Kubelet 同樣對外暴露了 HTTPS 服務，其使用者端主要是 Kube-apiserver 和一些監控元件，如 metric-server。Kube-apiserver 需要存取 Kubelet 來獲取容器的紀錄檔和執行命令（kubectl logs/exec)， 監控元件需要存取 Kubelet 暴露的 cadvisor 介面來獲取監控資訊。理想情況下，我們需要將 Kubelet 的 CA 證書設定到 Kube-apiserver 和 metric-server 中，以便於校驗 Kubelet 的伺服器端證書，保證安全性。但使用預設的叢集設定方法是無法做到這點的，需要做一些額外的工作。

Kubernetes 中除了 Kubelet 的伺服器端證書以外，其他證書都要由叢集根 CA（或是基於根CA的中間CA）簽發。 Kubelet 的證書則沒有這個要求。實際上，在 Kubelet 在啟動時，如果沒有指定伺服器端證書路徑，會建立一個自籤的 CA 證書，並使用該 CA 為自己簽發伺服器端證書。

Kubelet 伺服器端證書和使用者端證書生成邏輯不一樣，有以下三種情況，可自選：

  • 使用通過 --tls-private-key-file 和 --tls-cert-file 所設定的金鑰和證書，這樣每個節點的根證書有可能就不一樣
  • 如果沒有提供金鑰和證書，則建立自簽名的金鑰和證書，也會導致每個節點的根證書不一樣(如果 kubeadm init/join 沒有其他設定，預設都是這種情況)，Kubelet 每次重啟都會建立證書和私鑰
  • 通過 CSR API 從叢集伺服器請求服務證書

前面兩種情況就會導致每個節點的 Kubelet 的根 CA 可能都不一樣，這就導致使用者端元件，如 metric-server ，Kube-apiserver 都沒辦法校驗 Kubelet 的伺服器端證書。為了應對這種情況，metric-server 需要新增 *--kubelet-insecure-tls* 來跳過伺服器端證書的校驗，而 Kube-apiserver 預設不校驗 Kubelet 伺服器端證書。

第三種情況是 CSR 簽發者統一用叢集的根 CA 為各 Kubelet 簽發伺服器端證書，Kube-apiserver 和其他元件就可以通過設定叢集根 CA 來實現 HTTPS 的伺服器端證書校驗了。我們可以在 Kubelet 組態檔設定 *serverTLSBootstrap = true* 就可以啟用這項特性，使用 CSR 來申請伺服器端證書。這項設定同樣也會開啟伺服器端證書的自動輪換功能。不過這個過程並不是全自動的，在 CSR(CertificateSigningRequest) 章節中提到，Kubelet 的伺服器端證書 CSR 請求，即 *singerName* 為 *kubernetes.io/kubelet-serving* 的 CSR 請求，不會被 Kube-controller-manager 自動批准，也就是說我們需要手動批准這些 CSR，或者使用第三方控制器。

為什麼 Kubernetes 不自動批准 Kubelet 的伺服器端證書呢？這樣不是很方便嗎？原因是出於安全考量—— Kubernetes 沒有足夠的能力來辨別該 CSR 是否應該被批准。

HTTPS 伺服器端證書的重要作用就是向用戶端證明「我是我」，防止有人冒充「我」跟使用者端通訊，也就是防止中間人攻擊。在向權威 CA 機構申請證書時，我們要提供一系列證明材料，證明這個站點是我的，包括要證明我是該站點域名的所有者，CA 稽核通過後才會簽發證書。但 K8S 叢集本身是沒有足夠的能力來辨別 Kubelet 身份的，因為節點 IP，DNS 名稱可能發生變化，K8S 自身沒有足夠的能力判斷哪些 IP，哪些 DNS 是合法的，這屬於基礎設施管理者的職責範圍。如果你的叢集是雲廠商提供，那麼你的雲廠商可以提供對應的控制器來判斷 CSR 請求的合法性，批准合法的 CSR 請求。如果是自建叢集，那麼只有叢集管理員才能判斷 CSR 請求中包含的節點 IP，DNS 名稱是不是真實有效的。如果 Kube-controller-manager 自動簽發這些證書，則會產生中間人攻擊的風險。

假設節點 A 上的服務 bar 使用 HTTPS 暴露服務，並且伺服器端證書是通過 CSR 請求申請的，由叢集根 CA 簽發。假設有入侵者獲取了節點 A 的許可權，那他可以很方便的利用 Kubelet 的使用者端證書的許可權，建立一個 CSR 請求來申請一份 IP 為 bar service IP，DNS 名稱為 bar service DNS 的伺服器端證書。如果 Kube-controller-manager 自動通過並簽發這個證書，那入侵者就可以使用這個證書，配合節點上的 Kube-proxy，劫持所有經過 bar 服務的流量。

Service Account 認證

在 Kubernetes 叢集內部存取 Kube-apiserver 使用的是 Service Account ，如 pod 存取 Kube-apiserver

在 /etc/kubernetes/pki 目錄下，還有 sa.pub，sa.key 這兩個檔案沒有講解。這兩個就是用於 ServiceAccount 認證的，這兩個檔案是一對金鑰對，sa.pub 代表公鑰，sa.key 代表私鑰。

Kubernetes 叢集中還有個重要的系統元件 Kube-proxy，它也需要存取 Kube-apiserver，但是它和 Kube-controller-manager，Kube-scheduler 不一樣，它就是使用 ServiceAccount 來與 Kube-apiserver 進行認證，下面詳細看看。

當 Kube-proxy pod 在叢集中建立時，如果 Pod 沒有指定 ServiceAccount，kube-controller-manager 會預設建立一個沒有任何許可權的 ServiceAccount，同時 Kube-controller-manager 為該 ServiceAccount 生成一個 JWT token，並使用 secret 將該 token 掛載到 Pod 內部。

$ kubectl get  pod kube-proxy-6bf2t -n kube-system -o yaml
.....
  containers:
  - command:
    - /usr/local/bin/kube-proxy
    - --config=/var/lib/kube-proxy/config.conf
    - --hostname-override=$(NODE_NAME)
    ...
    volumeMounts:
    ...
		// token 檔案在 pod 的路徑
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-proxy-token-rd92l
      readOnly: true
  dnsPolicy: ClusterFirst
  .....
  volumes:
  ...
  - name: kube-proxy-token-rd92l
    secret:
      defaultMode: 420
      secretName: kube-proxy-token-rd92l

下面看看 secret 的內容

$ kubectl get secret -n kube-system kube-proxy-token-rd92l -o yaml
apiVersion: v1
data:
	// 該 ca 就是 Kubernetes 叢集中的 CA, 用於 pod 校驗 Kube-apiserver 的伺服器端證書
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01EZ3lNREF5TXpBd05Wb1hEVE13TURneE9EQXlNekF3TlZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSndoCmw4ZVd5SlBsSWpwajlTN09VSWRSTWVxV0Mwb2crN3hQemJQZDhzS2NTemZqWjdHc0ttUXlvQjhoQnNlaVVDdUwKai9teVl5Tk02MkxIa0ZKbDI3MXNFWVdmOEtiWS81Y210UmFjRnlMOEpyaTNLQi91eHZnZlEvMXhMK2c3UmRBcQpGQllWRzNtaSs1T1orTExyZlVMUU5qemtoTVllaEhDdHNDRmZJMGF5amJpYk1UUGJLT3lobjV3cHVMZzgvOVdlClNTSnI1TmtnK2R0WHJSZ05YelNpc1JMQVF5MmdEczdOaTN0SklaNjRuRGdIakpyS21HR2dqbEljN1RFdGFUdWcKcnltKy92akVZZ2NxTlhHakY2ekJlT1FXNW5NdUh0K1plYXphZ1QyQTNkUDhGY3lEWVZrSFJVd0RESDBZOVZlcwpOUFAyZnhURzVVZlhWOUV0WVJNQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFEajZLYXVQR2dvVnlGQmdNUzFZYlVFRXFHQmoKN3IwaG5vclNuOVp4dlUxZkM1UkZ0UEd0OEI0YU40T3RMa1REUno5ZmdFc1ZidFdoMXRXWURIWUF6N2FDYkVZawpMRTArRzZQMkpxR043SHlrd05BZFp1QS96emhOdVFKZnhjZG5qVHlIRWZXZyt5OEd1S2JqSU1QdFJVOU45bFpoCkZTeUxsYjNvektYbURDK2RuSHhHMXhNbnpCM05TQStYeGk3ZDVHakExemUzYXFxZXM2bWVONTNYWnFkeDE2N0gKLzNBNld6NjZ4UE9nOHlsUFNVa3R5bU1HNTFkOTFsdTFiZWJYUExtdmc0K3BBeFdhZGJGZ21MR0Z0UE1URXcrWgpIRHZzK3E2NDBIOWJpeitPV2Rld0hjUXE0TW9oQ1dubDhhVzVJYWVSYW1mWS9zZy8xd1NXMkZteGViQT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
  namespace: a3ViZS1zeXN0ZW0=
	// kube-contoller-manager 生成的 token
  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSnJkV0psTFhONWMzUmxiU0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVmpjbVYwTG01aGJXVWlPaUpyZFdKbExYQnliM2g1TFhSdmEyVnVMWEprT1RKc0lpd2lhM1ZpWlhKdVpYUmxjeTVwYnk5elpYSjJhV05sWVdOamIzVnVkQzl6WlhKMmFXTmxMV0ZqWTI5MWJuUXVibUZ0WlNJNkltdDFZbVV0Y0hKdmVIa2lMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzUxYVdRaU9pSmhOemRrTjJKaE1TMW1Zek5pTFRRM1lUTXRZV00wWkMweVpXRmtPVEV6WkRVd09ESWlMQ0p6ZFdJaU9pSnplWE4wWlcwNmMyVnlkbWxqWldGalkyOTFiblE2YTNWaVpTMXplWE4wWlcwNmEzVmlaUzF3Y205NGVTSjkuSTRuR0UxOVhJakFPU0lKcWZyb3A2azhHcXBickxBeVFzQ3NoeFhxMEc3RklTZmJudS1TTW9xV1pHUjU0S2hwREdlaGd6WkQwMGVGZG14bEM1ZzBIc2ZzZE40V0tmVFI1ZjY1b3kzTnVvWUxxcUIzUzgySUxLelJHREVBNHpwWmFXeG1lRmtzdU1mdl9UWDRjSGdtYUI3V0ZQZzJ5RWtxV0VPa3kwT0hOWnIxNmd4Mzl3S1owWDRhQ29FOVd0cGlZU1BKYU5SdmtVbENfNTlPZHJTYnBCYnlkd2JOaWVaRjdhcWRBbFdWQ3JXQkRfWmlCaHNnZklVYUpEcVg5TWtRbUpjVS1Yb2pzWUpXNFpNejZ3OEZFTHY4THpCazRLTUc5V185aG5Jc3FfVlFUM2xDek5iSHlNSktWeXZ1VlVrblo5X3AwaTJGQlpDeGVVdlpVazdrd01R
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: kube-proxy
    kubernetes.io/service-account.uid: a77d7ba1-fc3b-47a3-ac4d-2ead913d5082
  creationTimestamp: "2020-08-20T02:30:48Z"
  name: kube-proxy-token-rd92l
  namespace: kube-system
  resourceVersion: "196"
  selfLink: /api/v1/namespaces/kube-system/secrets/kube-proxy-token-rd92l
  uid: c9ff07a0-4176-4053-a93c-11c7d0aff285
type: kubernetes.io/service-account-token

Kube-controller-manager 用 sa.key 即私鑰對該 token 進行簽名。當 Pod 需要存取 Kube-apiserver 的時候，認證邏輯如下：

  • Pod 使用 secret 的 ca.crt 來校驗 Kube-apiserver 的伺服器端證書
  • Kube-apiserver 使用 sa.pub 即公鑰對 Pod 的 token 進行驗證，如果驗證成功，則認證通過

這樣就達到了 Pod 與 Kube-apiserver 雙向認證(這裡不是雙向 TLS 認證)，所以 ServiceAccount 這種認證方式屬於 Kube-apiserver 的 Token 認證。

下面是 ServiceAccout 認證流程圖：

sa.pub 和 sa.key 分別被設定到了 Kube-apiserver 和 Kube-controller-manager 的命令列引數中，如下所示：

/usr/local/bin/kube-apiserver \\ 
  --service-account-key-file=/etc/kubernetes/pki/sa.pub \\          # 用於驗證 service account token 的公鑰
  ...
  
 /usr/local/bin/kube-controller-manager \\
 --service-account-private-key-file=/etc/kubernetes/pki/sa.key      # 用於對 service account token 進行簽名的私鑰
 ...

總結

Kubernetes 證書系統還是比較複雜的，主要是涉及到雙向 TLS 認證，但是隻要能夠弄清楚元件之間相互呼叫的關係以及雙向 TLS 認證原理，就比較容易弄明白 Kubernetes 證書了。

以上主要是分析了 Kubernetes 叢集中所有的證書和元件如何使用證書的，對於 Kube-apiserver 來說，我們只分析了 Kube-apiserver 如何根據證書進行認證，後續如何根據證書進行鑑權還沒說。由於本篇篇幅較大，證書鑑權內容留到下一篇~

參照

https://juejin.cn/post/7016472622246395934