客戶端怎樣通過Kubernetes集群 API Server 認證？

前言

現在我們上微博、或者網購，操作的其實不是眼前這臺設備，而是一個又一個集群。通常，這樣的集群擁有成百上千個節點，每個節點是一臺物理機或虛擬機。集群一般遠離用戶，坐落在數據中心。為了讓這些節點互相協作，對外提供一致且高效的服務，集群需要操作系統。Kubernetes 就是這樣的操作系統。

比較 Kubernetes 和單機操作系統，Kubernetes 相當于內核，它負責集群軟硬件資源管理，并對外提供統一的入口，用戶可以通過這個入口來使用集群，和集群溝通。

而運行在集群之上的程序，與普通程序有很大的不同。這樣的程序，是“關在籠子里”的程序。它們從被制作，到被部署，再到被使用，都不尋常。我們只有深挖根源，才能理解其本質。

“關在籠子里”的程序

代碼

我們使用 go 語言寫了一個簡單的 web 服務器程序 app.go，這個程序監聽在 2580 這個端口。通過 http 協議訪問這個服務的根路徑，服務會返回 "This is a small app for kubernetes..." 字符串。

package main
import (
        "github.com/gorilla/mux"
        "log"
        "net/http"
)
func about(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("This is a small app for kubernetes...\n"))
}
func main() {
        r := mux.NewRouter()
        r.HandleFunc("/", about)
        log.Fatal(http.ListenAndServe("0.0.0.0:2580", r))
}

使用 go build 命令編譯這個程序，產生 app 可執行文件。這是一個普通的可執行文件，它在操作系統里運行，會依賴系統里的庫文件。

# ldd app
linux-vdso.so.1 => (0x00007ffd1f7a3000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f554fd4a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f554f97d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f554ff66000)

“籠子”

為了讓這個程序不依賴于操作系統自身的庫文件，我們需要制作容器鏡像，即隔離的運行環境。Dockerfile 是制作容器鏡像的“菜譜”。我們的菜譜就只有兩個步驟，下載一個 centos 的基礎鏡像，把 app 這個可執行文件放到鏡像中 /usr/local/bin 目錄中去。

FROM centos
ADD app /usr/local/bin

地址

制作好的鏡像存再本地，我們需要把這個鏡像上傳到鏡像倉庫里去。這里的鏡像倉庫，相當于應用商店。我們使用阿里云的鏡像倉庫，上傳之后鏡像地址是:

registry.cn-hangzhou.aliyuncs.com/kube-easy/app:latest

鏡像地址可以拆分成四個部分：倉庫地址/命名空間/鏡像名稱:鏡像版本。顯然，鏡像上邊的鏡像，在阿里云杭州鏡像倉庫，使用的命名空間是 kube-easy，鏡像名:版本是 app:latest。至此，我們有了一個可以在 Kubernetes 集群上運行的、“關在籠子里”的小程序。

入口

Kubernetes 作為操作系統，和普通的操作系統一樣，有 API 的概念。有了 API，集群就有了入口；有了 API，我們使用集群，才能得其門而入。Kubernetes 的 API 被實現為運行在集群節點上的組件 API Server。這個組件是典型的 web 服務器程序，通過對外暴露 http(s) 接口來提供服務。

這里我們創建一個阿里云 Kubernetes 集群。登錄集群管理頁面，我們可以看到 API Server 的公網入口。

API Server 內網連接端點： https://xx.xxx.xxx.xxx:6443

雙向數字證書驗證

阿里云 Kubernetes 集群 API Server 組件，使用基于 CA 簽名的雙向數字證書認證來保證客戶端與 api server 之間的安全通信。這句話很繞口，對于初學者不太好理解，我們來深入解釋一下。

從概念上來講，數字證書是用來驗證網絡通信參與者的一個文件。這和學校頒發給學生的畢業證書類似。在學校和學生之間，學校是可信第三方 CA，而學生是通信參與者。如果社會普遍信任一個學校的聲譽的話，那么這個學校頒發的畢業證書，也會得到社會認可。參與者證書和 CA 證書可以類比畢業證和學校的辦學許可證。

這里我們有兩類參與者，CA 和普通參與者；與此對應，我們有兩種證書，CA 證書和參與者證書；另外我們還有兩種關系，證書簽發關系以及信任關系。這兩種關系至關重要。

我們先看簽發關系。如下圖，我們有兩張 CA 證書，三個參與者證書。

其中最上邊的 CA 證書，簽發了兩張證書，一張是中間的 CA 證書，另一張是右邊的參與者證書；中間的 CA 證書，簽發了下邊兩張參與者證書。這六張證書以簽發關系為聯系，形成了樹狀的證書簽發關系圖。

然而，證書以及簽發關系本身，并不能保證可信的通信可以在參與者之間進行。以上圖為例，假設最右邊的參與者是一個網站，最左邊的參與者是一個瀏覽器，瀏覽器相信網站的數據，不是因為網站有證書，也不是因為網站的證書是 CA 簽發的，而是因為瀏覽器相信最上邊的 CA，也就是信任關系。

理解了 CA（證書），參與者（證書），簽發關系，以及信任關系之后，我們回過頭來看“基于 CA 簽名的雙向數字證書認證”。客戶端和 API Server 作為通信的普通參與者，各有一張證書。而這兩張證書，都是由 CA 簽發，我們簡單稱它們為集群 CA 和客戶端 CA。客戶端信任集群 CA，所以它信任擁有集群 CA 簽發證書的 API Server；反過來 API Server 需要信任客戶端 CA，它才愿意與客戶端通信。

阿里云 Kubernetes 集群，集群 CA 證書，和客戶端 CA 證書，實現上其實是一張證書，所以我們有這樣的關系圖。

KubeConfig 文件

登錄集群管理控制臺，我們可以拿到 KubeConfig 文件。這個文件包括了客戶端證書，集群 CA 證書，以及其他。證書使用 base64 編碼，所以我們可以使用 base64 工具解碼證書，并使用 openssl 查看證書文本。

• 首先，客戶端證書的簽發者 CN 是集群 id c0256a3b8e4b948bb9c21e66b0e1d9a72，而證書本身的 CN 是子賬號 252771643302762862；

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 787224 (0xc0318)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
        Validity
            Not Before: Nov 29 06:03:00 2018 GMT
            Not After : Nov 28 06:08:39 2021 GMT
        Subject: O=system:users, OU=, CN=252771643302762862

• 其次，只有在 API Server 信任客戶端 CA 證書的情況下，上邊的客戶端證書才能通過 API Server 的驗證。kube-apiserver 進程通過 client-ca-file 這個參數指定其信任的客戶端 CA 證書，其指定的證書是 /etc/kubernetes/pki/apiserver-ca.crt。這個文件實際上包含了兩張客戶端 CA 證書，其中一張和集群管控有關系，這里不做解釋，另外一張如下，它的 CN 與客戶端證書的簽發者 CN 一致；

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 787224 (0xc0318)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
        Validity
            Not Before: Nov 29 06:03:00 2018 GMT
            Not After : Nov 28 06:08:39 2021 GMT
        Subject: O=system:users, OU=, CN=252771643302762862

• 再次，API Server 使用的證書，由 kube-apiserver 的參數 tls-cert-file 決定，這個參數指向證書 /etc/kubernetes/pki/apiserver.crt。這個證書的 CN 是 kube-apiserver，簽發者是 c0256a3b8e4b948bb9c21e66b0e1d9a72，即集群 CA 證書；

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2184578451551960857 (0x1e512e86fcba3f19)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
        Validity
            Not Before: Nov 29 03:59:00 2018 GMT
            Not After : Nov 29 04:14:23 2019 GMT
        Subject: CN=kube-apiserver

• 最后，客戶端需要驗證上邊這張 API Server 的證書，因而 KubeConfig 文件里包含了其簽發者，即集群 CA 證書。對比集群 CA 證書和客戶端 CA 證書，發現兩張證書完全一樣，這符合我們的預期。

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 786974 (0xc021e)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=CN, ST=ZheJiang, L=HangZhou, O=Alibaba, OU=ACS, CN=root
        Validity
            Not Before: Nov 29 03:59:00 2018 GMT
            Not After : Nov 24 04:04:00 2038 GMT
        Subject: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72

訪問

理解了原理之后，我們可以做一個簡單的測試：以證書作為參數，使用 curl 訪問 api server，并得到預期結果。

# curl --cert ./client.crt --cacert ./ca.crt --key ./client.key https://xx.xx.xx.xxx:6443/api/
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.0.222:6443"
    }
  ]
}