kubernetes中TLS bootstrapping有什么用

這篇文章主要介紹了kubernetes中TLS bootstrapping有什么用，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

一： 前言

當集群開啟了 TLS 認證后，每個節點的 kubelet 組件都要使用由 apiserver 使用的 CA 簽發的有效證書才能與 apiserver 通訊；此時如果節點多起來，為每個節點單獨簽署證書將是一件非常繁瑣的事情；TLS bootstrapping 功能就是讓 kubelet 先使用一個預定的低權限用戶連接到 apiserver，然后向 apiserver 申請證書，kubelet 的證書由 apiserver 動態簽署；

Bootstrap 是很多系統中都存在的程序，比如 Linux 的bootstrap，bootstrap 一般都是作為預先配置在開啟或者系統啟動的時候加載，這可以用來生成一個指定環境。Kubernetes 的 kubelet 的啟動時同樣可以加載一個這樣的配置文件，這個文件的內容類似如下形式：
02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:kubelet-bootstrap"

在配合 RBAC 授權模型下的工作流程大致如下：


二：TLS bootstrapping 相關術語

1.kubernet相關端口

kubelet 組件在工作時，采用主動的查詢機制，即定期請求 apiserver 獲取自己所應當處理的任務，如哪些 pod 分配到了自己身上，從而去處理這些任務；同時 kubelet 自己還會暴露出兩個本身 api 的端口，用于將自己本身的私有 api 暴露出去，這兩個端口分別是 10250 與 10255；對于 10250 端口，kubelet 會在其上采用 TLS 加密以提供適當的鑒權功能；對于 10255 端口，kubelet 會以只讀形式暴露組件本身的私有 api，并且不做鑒權處理

就是說 kubelet 上實際上有兩個地方用到證書，一個是用于與 API server 通訊所用到的證書，另一個是 kubelet 的 10250 私有 api 端口需要用到的證書

2.CSR請求類型

kubelet 發起的 CSR 請求都是由 controller manager 來做實際簽署的，對于 controller manager 來說，TLS bootstrapping 下 kubelet 發起的 CSR 請求大致分為以下三種：
1. nodeclient ：用戶的客戶端認證請求 O=system:nodes ，CN=system:node:(node name) 。
2. selfnodeclient ：更新具有相同 O 和 CN 的客戶端證書的節點。
3. selfnodeserver ：更新服務證書的節點。

nodeclient 類型的 CSR 僅在第一次啟動時會產生，selfnodeclient 類型的 CSR 請求實際上就是 kubelet renew 自己作為 client 跟 apiserver 通訊時使用的證書產生的，selfnodeserver 類型的 CSR 請求則是 kubelet 首次申請或后續 renew 自己的 10250 api 端口證書時產生的

三、TLS bootstrapping 具體引導過程

1.TLS 作用
眾所周知 TLS 的作用就是對通訊加密，防止中間人竊聽；同時如果證書不信任的話根本就無法與 apiserver 建立連接，更不用提有沒有權限向 apiserver 請求指定內容。

2.RBAC 作用
當 TLS 解決了通訊問題后，那么權限問題就應由 RBAC 解決(可以使用其他權限模型，如 ABAC)；RBAC 中規定了一個用戶或者用戶組(subject)具有請求哪些 api 的權限；在配合 TLS 加密的時候，實際上 apiserver 讀取客戶端證書的 CN 字段作為用戶名，讀取 O 字段作為用戶組.

以上說明：第一，想要與 apiserver 通訊就必須采用由 apiserver CA 簽發的證書，這樣才能形成信任關系，建立 TLS 連接；第二，可以通過證書的 CN、O 字段來提供 RBAC 所需的用戶與用戶組。

3.kubelet 首次啟動流程
既然 TLS bootstrapping 功能是讓 kubelet 組件去 apiserver 申請證書，然后用于連接 apiserver；那么第一次啟動時沒有證書如何連接 apiserver ?

在 apiserver 配置中指定了一個 token.csv 文件，該文件中是一個預設的用戶配置；同時該用戶的 Token 和 apiserver 的 CA 證書被寫入了 kubelet 所使用的 bootstrap.kubeconfig 配置文件中；這樣在首次請求時，kubelet 使用 bootstrap.kubeconfig 中的 apiserver CA 證書來與 apiserver 建立 TLS 通訊，使用 bootstrap.kubeconfig 中的用戶 Token 來向 apiserver 聲明自己的 RBAC 授權身份.

首次啟動時，可能與遇到 kubelet 報 401 無權訪問 apiserver 的錯誤；這是因為在默認情況下，kubelet 通過 bootstrap.kubeconfig 中的預設用戶 Token 聲明了自己的身份，然后創建 CSR 請求；但是不要忘記這個用戶在我們不處理的情況下他沒任何權限的，包括創建 CSR 請求；所以需要如下命令創建一個 ClusterRoleBinding，將預設用戶 kubelet-bootstrap 與內置的 ClusterRole system:node-bootstrapper 綁定到一起，使其能夠發起 CSR 請求

點擊(此處)折疊或打開

1. cd /etc/kubernetes
   

2. export KUBE_APISERVER="https://x.x.x.x:6443"
   

3. # 設置集群參數
   

4. kubectl config set-cluster kubernetes \
   

5. --certificate-authority=/etc/kubernetes/ssl/ca.pem \
   

6. --embed-certs=true \
   

7. --server=${KUBE_APISERVER} \
   

8. --kubeconfig=bootstrap.kubeconfig

9. # 設置客戶端認證參數
   kubectl config set-credentials kubelet-bootstrap \
   --token=${BOOTSTRAP_TOKEN} \
   --kubeconfig=bootstrap.kubeconfig
   # 設置上下文參數
   kubectl config set-context default \
   --cluster=kubernetes \
   --user=kubelet-bootstrap \
   --kubeconfig=bootstrap.kubeconfig
   # 設置默認上下?
   kubectl config use-context default --kubeconfig=bootstrap.kubeco
   nfig
   

4.手動簽發證書
在 kubelet 首次啟動后，如果用戶 Token 沒問題，并且 RBAC 也做了相應的設置，那么此時在集群內應該能看到 kubelet 發起的 CSR 請求：

出現 CSR 請求后，可以使用 kubectl 手動簽發(允許) kubelet 的證書
kubectl certificate approve node-csr-ICyEqgl55a222oGUbA3U5CE22roAKo6AoGT6Eff_ehY

當成功簽發證書后，目標節點的 kubelet 會將證書寫入到 --cert-dir= 選項指定的目錄中
而 kubelet 與 apiserver 通訊所使用的證書為 kubelet-client.crt，剩下的 kubelet.crt 將會被用于 kubelet server(10250) 做鑒權使用；注意，此時 kubelet.crt 這個證書是個獨立于 apiserver CA 的自簽 CA，并且刪除后 kubelet 組件會重新生成它

四：證書及配置文件

1.token.csv
該文件為一個用戶的描述文件，基本格式為 Token,用戶名,UID,用戶組；這個文件在 apiserver 啟動時被 apiserver 加載，然后就相當于在集群內創建了一個這個用戶；接下來就可以用 RBAC 給他授權；持有這個用戶 Token 的組件訪問 apiserver 的時候，apiserver 根據 RBAC 定義的該用戶應當具有的權限來處理相應請求

2.bootstarp.kubeconfig
該文件中內置了 token.csv 中用戶的 Token，以及 apiserver CA 證書；kubelet 首次啟動會加載此文件，使用 apiserver CA 證書建立與 apiserver 的 TLS 通訊，使用其中的用戶 Token 作為身份標識像 apiserver 發起 CSR 請求

3.kubelet-client.crt
該文件在 kubelet 完成 TLS bootstrapping 后生成，此證書是由 controller manager 簽署的，此后 kubelet 將會加載該證書，用于與 apiserver 建立 TLS 通訊，同時使用該證書的 CN 字段作為用戶名，O 字段作為用戶組向 apiserver 發起其他請求

4.kubelet.crt
該文件在 kubelet 完成 TLS bootstrapping 后并且沒有配置 --feature-gates=RotateKubeletServerCertificate=true 時才會生成；這種情況下該文件為一個獨立于 apiserver CA 的自簽 CA 證書，有效期為 1 年；被用作 kubelet 10250 api 端口

5.apiserver配置文件

點擊(此處)折疊或打開

1. ###
   

2. ## kubernetes system config
   

3. ##
   

4. ## The following values are used to configure the kube-apiserver
   

5. ##
   

6. #
   

7. ## The address on the local server to listen to.
   

8. KUBE_API_ADDRESS="--advertise-address=10.116.137.196 --bind-address=10.116.137.196 --insecure-bind-address=10.116.137.196"
   

9. #
   

10. ## The port on the local server to listen on.
    

11. #KUBE_API_PORT="--port=8080"
    

12. #
    

13. ## Port minions listen on
    

14. #KUBELET_PORT="--kubelet-port=10250"
    

15. #
    

16. ## Comma separated list of nodes in the etcd cluster
    

17. KUBE_ETCD_SERVERS="--etcd-servers=https://10.116.137.196:2379,https://10.116.82.28:2379,https://10.116.36.57:2379"
    

18. #
    

19. ## Address range to use for services
    

20. KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
    

21. #
    

22. ## default admission control policies
    

23. KUBE_ADMISSION_CONTROL="--admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota"
    

24. #
    

25. ## Add your own!
    

26. KUBE_API_ARGS="--authorization-mode=RBAC --runtime-config=rbac.authorization.k8s.io/v1beta1 --kubelet-https=true --experimental-bootstrap-token-auth --token-auth-file=/etc/kubernetes/token.csv --service-node-port-range=30000-32767 --tls-cert-file=/etc/kubernetes/ssl/kubernetes.pem --tls-private-key-file=/etc/kubernetes/ssl/kubernetes-key.pem --client-ca-file=/etc/kubernetes/ssl/ca.pem --service-account-key-file=/etc/kubernetes/ssl/ca-key.pem --etcd-cafile=/etc/kubernetes/ssl/ca.pem --etcd-certfile=/etc/kubernetes/ssl/kubernetes.pem --etcd-keyfile=/etc/kubernetes/ssl/kubernetes-key.pem --enable-swagger-ui=true --apiserver-count=1 --audit-log-maxage=30 --audit-log-maxbackup=3 --audit-log-maxsize=100 --audit-log-path=/var/lib/audit.log --event-ttl=1h"

6.kubelet配置文件

點擊(此處)折疊或打開

1. ## kubelet (minion) config
   

2. #
   

3. ## The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces)
   

4. KUBELET_ADDRESS="--address=10.116.82.28"
   

5. #
   

6. ## The port for the info server to serve on
   

7. #KUBELET_PORT="--port=10250"
   

8. #
   

9. ## You may leave this blank to use the actual hostname
   

10. KUBELET_HOSTNAME="--hostname-override=10.116.82.28"
    

11. #
    

12. ## location of the api-server
    

13. #KUBELET_API_SERVER="--api-servers=http://10.116.137.196:8080"
    

14. #
    

15. ## pod infrastructure container
    

16. #KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=sz-pg-oam-docker-hub-001.tendcloud.com/library/pod-infrastructure:rhel7"
    

17. KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=registry.access.redhat.com/rhel7/pod-infrastructure"
    

18. #
    

19. ## Add your own!
    

20. KUBELET_ARGS="--cgroup-driver=systemd --cluster-dns=10.254.0.2 --experimental-bootstrap-kubeconfig=/etc/kubernetes/bootstrap.kubeconfig --kubeconfig=/etc/kubernetes/kubelet.kubeconfig --require-kubeconfig --cert-dir=/etc/kubernetes/ssl --cluster-domain=cluster.local. --hairpin-mode promiscuous-bridge --serialize-image-pulls=false --runtime-cgroups=/systemd/system.slice --kubelet-cgroups=/systemd/system.slice"

感謝你能夠認真閱讀完這篇文章，希望小編分享的“kubernetes中TLS bootstrapping有什么用”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!