一文帶你徹底釐清 Kubernetes 中的證書工作機制

搬磚者： 張首富
時  間： 2020-05-26
w   x： y18163201
原文地址：https://zhaohuabing.com/post/2020-05-19-k8s-certificate/

編者薦語：

本文試圖以一種比官方文檔更容易理解的方式來說明 Kubernetes 和證書（Certificate）相關的工作機制，如果你也存在這方面的疑惑，希望這篇文章對你有所幫助。

以下文章來源於趙化冰，作者趙化冰。

Kubernetes 組件的認證方式

首先讓我們來看一下 Kubernetes 中的組件：在 Kubernetes 中包含多個以獨立進程形式運行的組件，這些組件之間通過 HTTP/GRPC 相互通信，以協同完成集羣中應用的部署和管理工作。

kubernetes 組件，圖片來源kubernetes.io

從圖中可以看到，Kubernetes 控制平面中包含了 etctd，kube-api-server，kube-scheduler，kube-controller-manager 等組件，這些組件會相互進行遠程調用，例如 kube-api-server 會調用 etcd 接口存儲數據，kube-controller-manager 會調用 kube-api-server 接口查詢集羣中的對象狀態；同時，kube-api-server 也會和在工作節點上的 kubelet 和 kube-proxy 進行通信，以在工作節點上部署和管理應用。

以上這些組件之間的相互調用都是通過網絡進行的。在進行網絡通信時，通信雙方需要驗證對方的身份，以避免惡意第三方僞造身份竊取信息或者對系統進行***。爲了相互驗證對方的身份，通信雙方中的任何一方都需要做下面兩件事情：

向對方提供標明自己身份的一個證書
驗證對方提供的身份證書是否合法，是否僞造的？

在 Kubernetes 中使用了數字證書來提供身份證明，我們可以把數字證書簡單理解爲我們在日常生活中使用的“身份證”，上面標註了證書擁有者的身份信息，例如名稱，所屬組織機構等。爲了保證證書的權威性，會採用一個通信雙方都信任的 CA（證書機構，Certificate Authority）來頒發證書。這就類似於現實生活中頒發“身份證”的政府機構。數字證書中最重要的內容實際上是證書擁有者的公鑰，該公鑰代表了用戶的身份。本文假設讀者已經瞭解數字證書和 CA 的基本原理，如果你對此不太清楚，或者希望重新溫習一下相關知識，可以先閱讀一下這篇文章《數字證書原理》（https://zhaohuabing.com/post/2020-03-19-pki)。

CA （證書機構），圖片來源www.trustauth.cn

在 Kubernetes 的組件之間進行通信時，數字證書的驗證是在協議層面通過 TLS 完成的，除了需要在建立通信時提供相關的證書和密鑰外，在應用層面並不需要進行特殊處理。採用 TLS 進行驗證有兩種方式：

服務器單向認證：只需要服務器端提供證書，客戶端通過服務器端證書驗證服務的身份，但服務器並不驗證客戶端的身份。這種情況一般適用於對 Internet 開放的服務，例如搜索引擎網站，任何客戶端都可以連接到服務器上進行訪問，但客戶端需要驗證服務器的身份，以避免連接到僞造的惡意服務器。
雙向 TLS 認證：除了客戶端需要驗證服務器的證書，服務器也要通過客戶端證書驗證客戶端的身份。這種情況下服務器提供的是敏感信息，只允許特定身份的客戶端訪問。

在 Kubernetes 中，各個組件提供的接口中包含了集羣的內部信息。如果這些接口被非法訪問，將影響集羣的安全，因此組件之間的通信需要採用雙向 TLS 認證。即客戶端和服務器端都需要驗證對方的身份信息。在兩個組件進行雙向認證時，會涉及到下面這些證書相關的文件：

服務器端證書：服務器用於證明自身身份的數字證書，裏面主要包含了服務器端的公鑰以及服務器的身份信息。
服務器端私鑰：服務器端證書中包含的公鑰所對應的私鑰。公鑰和私鑰是成對使用的，在進行 TLS 驗證時，服務器使用該私鑰來向客戶端證明自己是服務器端證書的擁有者。
客戶端證書：客戶端用於證明自身身份的數字證書，裏面主要包含了客戶端的公鑰以及客戶端的身份信息。
客戶端私鑰：客戶端證書中包含的公鑰所對應的私鑰，同理，客戶端使用該私鑰來向服務器端證明自己是客戶端證書的擁有者。
服務器端 CA 根證書：簽發服務器端證書的 CA 根證書，客戶端使用該 CA 根證書來驗證服務器端證書的合法性。
客戶端端 CA 根證書：簽發客戶端證書的 CA 根證書，服務器端使用該 CA 根證書來驗證客戶端證書的合法性。

下面這張來自《The magic of TLS, X509 and mutual authentication explained》文章中的圖形象地解釋了雙向 TLS 認證的原理。如果你需要了解更多關於 TLS 認證的原理，可以閱讀一下 medium 上的原文(https://medium.com/sitewards/the-magic-of-tls-x509-and-mutual-authentication-explained-b2162dec4401)。

圖片來源The magic of TLS, X509 and mutual authentication explained

Kubernetes 中使用到的CA和證書

Kubernetes 中使用了大量的證書，本文不會試圖覆蓋到所有可能使用到的證書，但會討論到主要的證書。理解了這些證書的使用方法和原理後，也能很快理解其他可能遇到的證書文件。下圖標識出了在 kubernetes 中主要使用到的證書和其使用的位置：

Kubernetes 中使用到的主要證書

上圖中使用序號對證書進行了標註。圖中的箭頭表明了組件的調用方向，箭頭所指方向爲服務提供方，另一頭爲服務調用方。爲了實現 TLS 雙向認證，服務提供方需要使用一個服務器證書，服務調用方則需要提供一個客戶端證書，並且雙方都需要使用一個 CA 證書來驗證對方提供的證書。爲了簡明起見，上圖中只標註了證書使用方提供的證書，並沒有標註證書的驗證方驗證使用的 CA 證書。圖中標註的這些證書的作用分別如下：

etcd 集羣中各個節點之間相互通信使用的證書。由於一個 etctd 節點既爲其他節點提供服務，又需要作爲客戶端訪問其他節點，因此該證書同時用作服務器證書和客戶端證書。
etcd 集羣向外提供服務使用的證書。該證書是服務器證書。
kube-apiserver 作爲客戶端訪問 etcd 使用的證書。該證書是客戶端證書。
kube-apiserver 對外提供服務使用的證書。該證書是服務器證書。
kube-controller-manager 作爲客戶端訪問 kube-apiserver 使用的證書,該證書是客戶端證書。
kube-scheduler 作爲客戶端訪問 kube-apiserver 使用的證書,該證書是客戶端證書。
kube-proxy 作爲客戶端訪問 kube-apiserver 使用的證書,該證書是客戶端證書。
kubelet 作爲客戶端訪問 kube-apiserver 使用的證書,該證書是客戶端證書。
管理員用戶通過 kubectl 訪問 kube-apiserver 使用的證書,該證書是客戶端證書。
kubelet 對外提供服務使用的證書。該證書是服務器證書。
kube-apiserver 作爲客戶端訪問 kubelet 採用的證書。該證書是客戶端證書。
kube-controller-manager 用於生成和驗證 service-account token 的證書。該證書並不會像其他證書一樣用於身份認證，而是將證書中的公鑰/私鑰對用於 service account token 的生成和驗證。kube-controller-manager 會用該證書的私鑰來生成 service account token，然後以 secret 的方式加載到 pod 中。pod 中的應用可以使用該 token 來訪問 kube-apiserver， kube-apiserver 會使用該證書中的公鑰來驗證請求中的 token。我們將在文中稍後部分詳細介紹該證書的使用方法。

通過這張圖，對證書機制比較瞭解的讀者可能已經看出，我們其實可以使用多個不同的 CA 來頒發這些證書。只要在通信的組件中正確配置用於驗證對方證書的 CA 根證書，就可以使用不同的 CA 來頒發不同用途的證書。但我們一般建議採用統一的 CA 來頒發 kubernetes 集羣中的所有證書，這是因爲採用一個集羣根 CA 的方式比採用多個 CA 的方式更容易管理，可以避免多個CA 導致的複雜的證書配置、更新等問題，減少由於證書配置錯誤導致的集羣故障。

Kubernetes 中的證書配置

前面我們介紹了 Kubernetes 集羣中主要使用到的證書。下面我們分別看一下如何將這些證書及其對應的私鑰和 CA 根證書需要配置到 Kubernetes 中各個組件中，以供各個組件進行使用。這裏假設使用一個集羣根 CA 來頒發所有相關證書，因此涉及到 CA 的配置對應的證書文件名都是相同的。

etcd 證書配置

需要在 etcd 的啓動命令行中配置以下證書相關參數：

etcd 對外提供服務的服務器證書及私鑰。
etcd 節點之間相互進行認證的 peer 證書、私鑰以及驗證 peer 的 CA。
etcd 驗證訪問其服務的客戶端的 CA。

/usr/local/bin/etcd \\
  --cert-file=/etc/etcd/kube-etcd.pem \\                   # 對外提供服務的服務器證書
  --key-file=/etc/etcd/kube-etcd-key.pem \\                # 服務器證書對應的私鑰
  --peer-cert-file=/etc/etcd/kube-etcd-peer.pem \\         # peer 證書，用於 etcd 節點之間的相互訪問
  --peer-key-file=/etc/etcd/kube-etcd-peer-key.pem \\      # peer 證書對應的私鑰
  --trusted-ca-file=/etc/etcd/cluster-root-ca.pem \\       # 用於驗證訪問 etcd 服務器的客戶端證書的 CA 根證書
  --peer-trusted-ca-file=/etc/etcd/cluster-root-ca.pem\\   # 用於驗證 peer 證書的 CA 根證書
  ...

kube-apiserver 證書配置

需要在 kube-apiserver 中配置以下證書相關參數：

kube-apiserver 對外提供服務的服務器證書及私鑰。
kube-apiserver 訪問 etcd 所需的客戶端證書及私鑰。
kube-apiserver 訪問 kubelet 所需的客戶端證書及私鑰。
驗證訪問其服務的客戶端的 CA。
驗證 etcd 服務器證書的 CA 根證書。
驗證 service account token 的公鑰。

/usr/local/bin/kube-apiserver \\ 
  --tls-cert-file=/var/lib/kubernetes/kube-apiserver.pem \\                             # 用於對外提供服務的服務器證書
  --tls-private-key-file=/var/lib/kubernetes/kube-apiserver-key.pem \\                  # 服務器證書對應的私鑰
  --etcd-certfile=/var/lib/kubernetes/kube-apiserver-etcd-client.pem \\                 # 用於訪問 etcd 的客戶端證書
  --etcd-keyfile=/var/lib/kubernetes/kube-apiserver-etcd-client-key.pem \\              # 用於訪問 etcd 的客戶端證書的私鑰
  --kubelet-client-certificate=/var/lib/kubernetes/kube-apiserver-kubelet-client.pem \\ # 用於訪問 kubelet 的客戶端證書
  --kubelet-client-key=/var/lib/kubernetes/kube-apiserver-kubelet-client-key.pem \\     # 用於訪問 kubelet 的客戶端證書的私鑰
  --client-ca-file=/var/lib/kubernetes/cluster-root-ca.pem \\                           # 用於驗證訪問 kube-apiserver 的客戶端的證書的 CA 根證書
  --etcd-cafile=/var/lib/kubernetes/cluster-root-ca.pem \\                              # 用於驗證 etcd 服務器證書的 CA 根證書  
  --kubelet-certificate-authority=/var/lib/kubernetes/cluster-root-ca.pem \\            # 用於驗證 kubelet 服務器證書的 CA 根證書
  --service-account-key-file=/var/lib/kubernetes/service-account.pem \\                 # 用於驗證 service account token 的公鑰
  ...

採用 kubeconfig 訪問 kube-apiserver

Kubernetes 中的各個組件，包括kube-controller-mananger、kube-scheduler、kube-proxy、kubelet等，採用一個kubeconfig 文件中配置的信息來訪問 kube-apiserver。該文件中包含了 kube-apiserver 的地址，驗證 kube-apiserver 服務器證書的 CA 證書，自己的客戶端證書和私鑰等訪問信息。

在一個使用 minikube 安裝的集羣中，生成的 kubeconfig 配置文件如下所示，這四個文件分別爲 admin 用戶， kube-controller-mananger、kubelet 和 kube-scheduler 的kubeconfig配置文件。

$ ls /etc/kubernetes/
admin.conf  controller-manager.conf  kubelet.conf  scheduler.conf

我們打開 controller-manager.conf 來看一下。

apiVersion: v1
clusters:
- cluster:
    # 用於驗證 kube-apiserver 服務器證書的 CA 根證書

    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQVRBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwdGFXNXAKYTNWaVpVTkJNQjRYRFRJd01ETXdOekF3TXpjeE1Wb1hEVE13TURNd05qQXdNemN4TVZvd0ZURVRNQkVHQTFVRQpBeE1LYldsdWFXdDFZbVZEUVRDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTTczCkdIMWxqNkxEUm1FLy9hQ2cvNUlmampKYy8zOGcyMVpITXJDMkx5RGVqZWhrdWUwZFB1WTJ0L2JjTjJYM1dGNEsKaWNzNmhhWnBDbFVxL3pteVRITWhhZnlmVVF5MDFJZmhDV2I5NXI4akpHZ2NyU3U3UUtXM3ZOd1Z1TmhJNmd6SApSWW45Ry82VHJKTjdOMWRjejNmMlU1OFRjUHVCQzZOUzVTc1JmemFSczVDZnd0UTNaa2czQUFVYTlQSDZFVmtDCkIvRGR1bXBialZGakMwSllOWlFVNTlGNUxDeHJ0bEYvOUJsSVhnZGw0ZlNCNzQ0ZW1UelcySEZQek9lTklYYnUKYTJPa0FFTDdJc3hSRTFBaEFKZ1h6cFNmdi9paDBuMEJpQ1VaV1hLZjg2UjZJL2xlK2docG51c21kTXUwbkNEUApHMm9laXhRTit5NzFQU2tGcGdzQ0F3RUFBYU5DTUVBd0RnWURWUjBQQVFIL0JBUURBZ0trTUIwR0ExVWRKUVFXCk1CUUdDQ3NHQVFVRkJ3TUNCZ2dyQmdFRkJRY0RBVEFQQmdOVkhSTUJBZjhFQlRBREFRSC9NQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFCaWpXYlpPNU9uaU9lNHRHUlQvRGFXaFBkY2ZwbE8vcVQ5WkFqU1hXZU41TStubExQZQpGV1NLRGRWU1NzajJ6UVdMU3A1Vjc3MkFoa2NYQlM0a2ZiY2ZCTUl2ejVsYXJZeHgxcnduTzZLbVZSTHdkNUNkCnRER2RjUjF0UzdqeTRSV05ISlAyNWZhZHB5TE9KVzJlZkdLRmRiSnZyRjljekV1ODR5a1drdThtVnNNa0RzTXkKbnVFNGtXblNvODgweFpxVG9QN01qM3hkRlNYYWdoNytwK3FMazk1VjhBNTRUNmRKa2VjSGg4SzdNYVRxdWVOVgpzOVhuZDA2WEJGQWFCVXRsSGZybmRXUzhmaTQ5dTY0NEFWOWJHclNYRnR1Q0lydnIxVkY2d0R3dEJYZi9UUStrCkx3Zk1oNVZDVWt1bEJqWEpqK1ZvRnBLZm5Qck9nbEExZzRtUgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    server: https://localhost:8443
  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:
    # 用於訪問 kube-apiserver 的客戶端證書

    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lJZVE4aDNXSlNmZEF3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2JXbHVhV3QxWW1WRFFUQWVGdzB5TURBek1EY3dNRE0zTVRGYUZ3MHlNVEExTVRrd05qVTNNemxhTUNreApKekFsQmdOVkJBTVRIbk41YzNSbGJUcHJkV0psTFdOdmJuUnliMnhzWlhJdGJXRnVZV2RsY2pDQ0FTSXdEUVlKCktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQU5DTzJpTEZzNGRTTW9sR2plN2tjY1VFbURDVjEvbWQKV1p1cS9DT0RvV1p2Uy80clNrOXNsaFQvektIVTVkVmg3SFV4TGNWU1RkQXZScGEwN3dXK3h2eWlDR3Y5UmMyVAp0bkFnUFFhQ2VkOC8zZlFpMzI1QmZCZVl4UjRTTm8raEM1b0ZYYkhpdC9OWWlQTVMvM1hFOGVCc0dEZCtjd1pzCnhNTDZzc0pJNzVOSmNXckV3eXlMbzIrb1JSRmJ2TlpJWFRZekJpRGd3QkZxNUkzZVA5QTl2d29rUG5STFBSdlYKQU9SV3hUZDMyblJLOTY1SU9uV25mNzY0bHhSeEV6bHIyS09rSzc5NlVJWTlyL0lYOWdGQjNqbGZFK1lBOE5VLwpuV2x3cElNL0ZpMk9hL1hjNnQzNUJHSnNXcTR4bHQ5RDdqS3V2bTNONmJlanJPOFZNODU5QU44Q0F3RUFBYU1uCk1DVXdEZ1lEVlIwUEFRSC9CQVFEQWdXZ01CTUdBMVVkSlFRTU1Bb0dDQ3NHQVFVRkJ3TUNNQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFCZVg4QmVuTlJoUTVWaVpMMjRxcWxIMjRlMDVyYWVVTFZJQlQzWE90cmdQcXF1WXRGWgptRG9naEpuSW05aVVMcHFTTUxHMlJrQ0RBMEk2Rit0SGVFVHRMRDlNdjA2N1huQ2VCclhkTFVTYzkwaHNZWm1KClNsVG11c21TZGUxUXJsRnFxQVRZY2VCVWgwM0lSbXZIL1BtS21va1FUZDZER0paVVVhM3ducEN6Nko4aGcySGwKWlZFaURKcHNoeXNBaVdCUWZBN01TRlFlb0poSjhUdHgzdEhNZDlaaHlmcVVHOVByUGJkMUlBQTIrRlVudXRsNwpoRmdZdTBxbG5aZFZCWE9JM1dvZndWZ2dDTEQrbFVCeGgzNVhLNStxYXhWNVlDTit0ZTNFeDJERHVmRW1UV0FoCkwwUVNTc0RTZGd0Vi9TNFhvV2xQcXU0Q2lRVnZydUg3WHkxMwotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    # 客戶端證書對應的私鑰

    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBMEk3YUlzV3poMUl5aVVhTjd1Unh4UVNZTUpYWCtaMVptNnI4STRPaFptOUwvaXRLClQyeVdGUC9Nb2RUbDFXSHNkVEV0eFZKTjBDOUdsclR2QmI3Ry9LSUlhLzFGelpPMmNDQTlCb0o1M3ovZDlDTGYKYmtGOEY1akZIaEkyajZFTG1nVmRzZUszODFpSTh4TC9kY1R4NEd3WU4zNXpCbXpFd3ZxeXdranZrMGx4YXNURApMSXVqYjZoRkVWdTgxa2hkTmpNR0lPREFFV3JramQ0LzBEMi9DaVErZEVzOUc5VUE1RmJGTjNmYWRFcjNya2c2CmRhZC92cmlYRkhFVE9XdllvNlFydjNwUWhqMnY4aGYyQVVIZU9WOFQ1Z0R3MVQrZGFYQ2tnejhXTFk1cjlkenEKM2ZrRVlteGFyakdXMzBQdU1xNitiYzNwdDZPczd4VXp6bjBBM3dJREFRQUJBb0lCQVFDRDVMT2pKZkJoZGVRcgoySWpPT1g2Um9GUTI5YXgrV2JwZnJnU0MyUzNyUUJ1SkJBdWNxd2xIQW5hQktjaW41NlBJZ1c5MnlKUVpRcXliCmhwVmF4c25FM3h3QVgwNFRzb1MvNkVOdnFIZzJiWWVLYTd0dFdOQ0hnNysxUXNOcWxlaG1ZVnBkc3dtdVJhRm0KUis5eXBUaHFPeklkZGtSOEhiRlp0WDN6VEhqbVpYaUhGdlIvMFhYK1BVbDR6SllSWjlCbVBnY2Ric2tSTldScgo0Qk8wUmlQQWRKVEo2VHZLMGhxT1g1UHo4ekl3S1ZzYjdyYndUdXArTGs4eWNCVUd3Q1N3RzEyanVNQW1kYkJJClZmdmlFK1VYRHRIQXdLWXlnMEhCVitJVlEvcVNwSVJ1WXQ4SmY1MWVKN1VEbHhiN3ZRTStEYVNsNjVaMVNyWUcKQU9UTGpPVkJBb0dCQU5PYzB0OG5ybmhUR3V0MGhMdVp6SWs4ekFranhYYWtiSURlZi9XeXlQdW94Z3J2ZGMzcwpsbHV0U3hSOFV4WGVuQjBLZFpnYnNoc1ozeW9GbEI0YThTMzI1UFRsYm9xOVB0TDRaOFBzczQ3L0l1bHYxTk10CnZzZjdKZ1FuaFRCVndkdjN6OXFpdml6bjB4Mk9CdURxdzNSYXcvWEhwRy9RczJ5WmF4S29GNW9SQW9HQkFQeE8KQVBDUXQ2Q2swOFF2WTE4VjFLQXA0d2h1YWEyMS9MeC9rZUZJSURRd0tZZnFHRGdBWUYvQzJUbC9xc29TMXAvTwpFcFVkVkRBNHVpblFVbnFhNGg0a0JOYjRXTFhrSXhRdXdjWHdJNjRMNWR3ZWJHalhxUWUwbnkxQkhkTmU2Z0dqClorbit4OUJLWnJmcEliYkQ2blpYUUREbS9jZWYyWU5NVWRqVWpudnZBb0dBQnlIMUZhSi94ZngvSHNxWm9yMG4KWU1UVTE4WUY1TjdiN1dnU2hoU1ZvNjNucHZ5MVN0Q2JyTkZsZzNaQlVxNWpNck5ralZENXF1SXZYSG85cU5vZApvUC8rYmFiQ0dCa1M0Z2VQYjlJdHB6ZEFWUC80KzNsQ1FmbGNLYTJ2VnBhOVp3MnVTdDlMYTdZUXJxRlg2QUxoCnZhMUZoNlpJQzZETU8yL2NaUStYWkJFQ2dZQnNGMHNGeFNvMlU0YzZISWM1SEZRc2plVnJIa3ArRm1LQnF6R24KVDB3a3I2R0xUZm8wTzgwT0daOFFxQ1pXVGozTzF1MVZIdXlMZ0RJWmFkdDhGVkRjVXRnVDlPK2tkV21sNHVZMwpVOHNsYklsOGhUZ3lybm9IQ0JYTndJRHpwazBnaUk0alRIajBQbnZGUE1hcDAwTm1rYmk1ZXF5czBrblFtMmpSCk9UY1Yxd0tCZ0RNUWZSVlNNNXlGcjVIalJ4UXcwRDdrUWhONDlLbngrMWs2bWRORWJ6VG9rQ1RRcWlSeUJQdGgKcjlqZk0rRXFZcnZ1elRmRVpiS1VBMEZac09yeStxMHpXb29mTURLajFGV3BaTXJBSmdxdDFlcWtFbVFrVi8vSApQMzF3ejZDa1RneDdJby9iZ09PbmhsbUplU3NHaXpqenV2TjFEcWtjNVR3M3oxUSs1dmxmCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

可以看到，訪問 kube-apiserver 所需要的相關證書內容已經被採用 base64 編碼寫入了文件中。其他幾個文件中的內容也是類似的，只是配置的用戶名和客戶端證書有所不同。

在啓動這些組件時，需要在參數中指出 kubeconfig 文件的路徑，例如 kube-controller-manager 的啓動命令如下。

/usr/local/bin/kube-controller-manager \\
 --kubeconfig=/etc/kubernetes/controller-manager.conf
 # 下面幾個證書和訪問 kube-apiserver 無關，我們會在後面介紹到
 --cluster-signing-cert-file=/var/lib/kubernetes/cluster-root-ca.pem             # 用於簽發證書的 CA 根證書
 --cluster-signing-key-file=/var/lib/kubernetes/cluster-root-ca-key.pem          # 用於簽發證書的 CA 根證書的私鑰  
 --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem  # 用於對 service account token 進行簽名的私鑰
 ...

Service Account 證書

Kubernetes 中有兩類用戶，一類爲 user account，一類爲 service account。service account 主要被 pod 用於訪問 kube-apiserver。在爲一個 pod 指定了 service account 後，kubernetes 會爲該 service account 生成一個 JWT token，並使用 secret 將該 service account token 加載到 pod 上。pod 中的應用可以使用 service account token 來訪問 api server。service account 證書被用於生成和驗證 service account token。該證書的用法和前面介紹的其他證書不同，因爲實際上使用的是其公鑰和私鑰，而並不需要對證書進行驗證。

我們可以看到 service account 證書的公鑰和私鑰分別被配置到了 kube-apiserver 和 kube-controller-manager 的命令行參數中，如下所示：

/usr/local/bin/kube-apiserver \\ 
  --service-account-key-file=/var/lib/kubernetes/service-account.pem \\          # 用於驗證 service account token 的公鑰
  ...

 /usr/local/bin/kube-controller-manager \\
 --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem  # 用於對 service account token 進行簽名的私鑰
 ...

下圖展示了 kubernetes 中生成、使用和驗證 service account token 的過程。

認證方法：客戶端證書還是 token ？

從前面的介紹中我們可以看到，Kubernetes 提供了兩種客戶端認證的方法，控制面組件採用的是客戶端數字證書;而在集羣中部署的應用則採用了 service account token 的方式。爲什麼 Kubernetes 不爲 service account 也生成一個證書，並採用該證書進行身份認證呢？實際上 Istio 就是這樣做的，Istio 會自動爲每個 service account 生成一個證書，並使用該證書來在 pod 中的應用之間建立雙向 tls 認證。我沒有找到 Kubernetes 這個設計決策的相關說明，如果你知道原因，歡迎和我聯繫探討。

Kubernetes 證書籤發

Kubernetes 提供了一個 certificates.k8s.io API，可以使用配置的 CA 根證書來簽發用戶證書。該 API 由 kube-controller-manager 實現，其簽發證書使用的根證書在下面的命令行中進行配置。我們希望 Kubernetes 採用集羣根 CA 來簽發用戶證書，因此在 kube-controller-manager 的命令行參數中將相關參數配置爲了集羣根 CA。

 /usr/local/bin/kube-controller-manager \\
 --cluster-signing-cert-file=/var/lib/kubernetes/cluster-root-ca.pem             # 用於簽發證書的 CA 根證書
 --cluster-signing-key-file=/var/lib/kubernetes/cluster-root-ca-key.pem          # 用於簽發證書的 CA 根證書的私鑰  
 ...

關於更多 Kubernetes 證書籤發 API 的內容，可以參見管理集羣中的 TLS 認證。

使用 TLS bootstrapping 簡化 Kubelet 證書製作

在安裝 Kubernetes 時，我們需要爲每一個工作節點上的 Kubelet 分別生成一個證書。由於工作節點可能很多，手動生成 Kubelet 證書的過程會比較繁瑣。爲了解決這個問題，Kubernetes 提供了 TLS bootstrapping (https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 的方式來簡化 Kubelet 證書的生成過程。其原理是預先提供一個 bootstrapping token，kubelet 通過該 kubelet 調用 kube-apiserver 的證書籤發 API 來生成自己需要的證書。要啓用該功能，需要在 kube-apiserver 中啓用 --enable-bootstrap-token-auth ，並創建一個 kubelet 訪問 kube-apiserver 使用的 bootstrap token secret。如果使用 kubeadmin 安裝，可以使用 kubeadm token create命令來創建 token。

採用TLS bootstrapping 生成證書的流程如下：

調用 kube-apiserver 生成一個 bootstrap token。
將該 bootstrap token 寫入到一個 kubeconfig 文件中，作爲 kubelet 調用 kube-apiserver 的客戶端驗證方式。
通過 --bootstrap-kubeconfig 啓動參數將 bootstrap token 傳遞給 kubelet 進程。
Kubelet 採用bootstrap token 調用 kube-apiserver API，生成自己所需的服務器和客戶端證書。
證書生成後，Kubelet 採用生成的證書和 kube-apiserver 進行通信，並刪除本地的 kubeconfig 文件，以避免 bootstrap token 泄漏風險。

小結

Kubernetes 中使用了大量的證書來確保集羣的安全，弄清楚這些證書的用途和配置方法將有助於我們深入理解 kubernetes 的安裝過程和組件的配置。本文是筆者在學習過程中整理的 Kubernetes 集羣中主要使用到的證書，由於筆者對 Kubernetes 的理解有限，文章中難免存在部分錯誤，歡迎指正。

本文轉載：https://zhaohuabing.com/post/2020-05-19-k8s-certificate/

一文帶你徹底釐清 Kubernetes 中的證書工作機制

一文帶你徹底釐清 Kubernetes 中的證書工作機制

編者薦語：

Kubernetes 組件的認證方式

Kubernetes 中使用到的CA和證書

Kubernetes 中的證書配置

etcd 證書配置

kube-apiserver 證書配置

採用 kubeconfig 訪問 kube-apiserver

Service Account 證書

認證方法：客戶端證書還是 token ？

Kubernetes 證書籤發

使用 TLS bootstrapping 簡化 Kubelet 證書製作

小結

Python 潮流週刊#50：我最喜歡的 Python 3.13 新特性！

docker stop 或者 docker kill 不能停止容器

一文帶你徹底釐清 Kubernetes 中的證書工作機制

docker 倉庫裏面python好多tag都代表什麼意思？我們該如何選擇

MFS（MooseFS分佈式文件系統）

docker 掛載文件不同步問題記錄

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結