客戶端怎樣通過Kubernetes集群APIServer認(rèn)證？

前言

我們提供的服務(wù)有：網(wǎng)站設(shè)計(jì)、成都網(wǎng)站設(shè)計(jì)、微信公眾號(hào)開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、大姚ssl等。為1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的大姚網(wǎng)站制作公司

現(xiàn)在我們上微博、或者網(wǎng)購，操作的其實(shí)不是眼前這臺(tái)設(shè)備，而是一個(gè)又一個(gè)集群。通常，這樣的集群擁有成百上千個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)是一臺(tái)物理機(jī)或虛擬機(jī)。集群一般遠(yuǎn)離用戶，坐落在數(shù)據(jù)中心。為了讓這些節(jié)點(diǎn)互相協(xié)作，對(duì)外提供一致且高效的服務(wù)，集群需要操作系統(tǒng)。Kubernetes 就是這樣的操作系統(tǒng)。

比較 Kubernetes 和單機(jī)操作系統(tǒng)，Kubernetes 相當(dāng)于內(nèi)核，它負(fù)責(zé)集群軟硬件資源管理，并對(duì)外提供統(tǒng)一的入口，用戶可以通過這個(gè)入口來使用集群，和集群溝通。

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

“關(guān)在籠子里”的程序

代碼

我們使用 go 語言寫了一個(gè)簡(jiǎn)單的 web 服務(wù)器程序 app.go，這個(gè)程序監(jiān)聽在 2580 這個(gè)端口。通過 http 協(xié)議訪問這個(gè)服務(wù)的根路徑，服務(wù)會(huì)返回 "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 命令編譯這個(gè)程序，產(chǎn)生 app 可執(zhí)行文件。這是一個(gè)普通的可執(zhí)行文件，它在操作系統(tǒng)里運(yùn)行，會(huì)依賴系統(tǒng)里的庫文件。

# 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)

“籠子”

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

FROM centos
ADD app /usr/local/bin

地址

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

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

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

入口

Kubernetes 作為操作系統(tǒng)，和普通的操作系統(tǒng)一樣，有 API 的概念。有了 API，集群就有了入口；有了 API，我們使用集群，才能得其門而入。Kubernetes 的 API 被實(shí)現(xiàn)為運(yùn)行在集群節(jié)點(diǎn)上的組件 API Server。這個(gè)組件是典型的 web 服務(wù)器程序，通過對(duì)外暴露 http(s) 接口來提供服務(wù)。

這里我們創(chuàng)建一個(gè)阿里云 Kubernetes 集群。登錄集群管理頁面，我們可以看到 API Server 的公網(wǎng)入口。

API Server 內(nèi)網(wǎng)連接端點(diǎn)： https://xx.xxx.xxx.xxx:6443

雙向數(shù)字證書驗(yàn)證

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

從概念上來講，數(shù)字證書是用來驗(yàn)證網(wǎng)絡(luò)通信參與者的一個(gè)文件。這和學(xué)校頒發(fā)給學(xué)生的畢業(yè)證書類似。在學(xué)校和學(xué)生之間，學(xué)校是可信第三方 CA，而學(xué)生是通信參與者。如果社會(huì)普遍信任一個(gè)學(xué)校的聲譽(yù)的話，那么這個(gè)學(xué)校頒發(fā)的畢業(yè)證書，也會(huì)得到社會(huì)認(rèn)可。參與者證書和 CA 證書可以類比畢業(yè)證和學(xué)校的辦學(xué)許可證。

這里我們有兩類參與者，CA 和普通參與者；與此對(duì)應(yīng)，我們有兩種證書，CA 證書和參與者證書；另外我們還有兩種關(guān)系，證書簽發(fā)關(guān)系以及信任關(guān)系。這兩種關(guān)系至關(guān)重要。

我們先看簽發(fā)關(guān)系。如下圖，我們有兩張 CA 證書，三個(gè)參與者證書。

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

然而，證書以及簽發(fā)關(guān)系本身，并不能保證可信的通信可以在參與者之間進(jìn)行。以上圖為例，假設(shè)最右邊的參與者是一個(gè)網(wǎng)站，最左邊的參與者是一個(gè)瀏覽器，瀏覽器相信網(wǎng)站的數(shù)據(jù)，不是因?yàn)榫W(wǎng)站有證書，也不是因?yàn)榫W(wǎng)站的證書是 CA 簽發(fā)的，而是因?yàn)闉g覽器相信最上邊的 CA，也就是信任關(guān)系。

理解了 CA（證書），參與者（證書），簽發(fā)關(guān)系，以及信任關(guān)系之后，我們回過頭來看“基于 CA 簽名的雙向數(shù)字證書認(rèn)證”?？蛻舳撕?API Server 作為通信的普通參與者，各有一張證書。而這兩張證書，都是由 CA 簽發(fā)，我們簡(jiǎn)單稱它們?yōu)榧?CA 和客戶端 CA?？蛻舳诵湃渭?CA，所以它信任擁有集群 CA 簽發(fā)證書的 API Server；反過來 API Server 需要信任客戶端 CA，它才愿意與客戶端通信。

阿里云 Kubernetes 集群，集群 CA 證書，和客戶端 CA 證書，實(shí)現(xiàn)上其實(shí)是一張證書，所以我們有這樣的關(guān)系圖。

KubeConfig 文件

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

• 首先，客戶端證書的簽發(fā)者 CN 是集群 id c0256a3b8e4b948bb9c21e66b0e1d9a72，而證書本身的 CN 是子賬號(hào) 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 的驗(yàn)證。kube-apiserver 進(jìn)程通過 client-ca-file 這個(gè)參數(shù)指定其信任的客戶端 CA 證書，其指定的證書是 /etc/kubernetes/pki/apiserver-ca.crt。這個(gè)文件實(shí)際上包含了兩張客戶端 CA 證書，其中一張和集群管控有關(guān)系，這里不做解釋，另外一張如下，它的 CN 與客戶端證書的簽發(fā)者 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 的參數(shù) tls-cert-file 決定，這個(gè)參數(shù)指向證書 /etc/kubernetes/pki/apiserver.crt。這個(gè)證書的 CN 是 kube-apiserver，簽發(fā)者是 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

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

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

訪問

理解了原理之后，我們可以做一個(gè)簡(jiǎn)單的測(cè)試：以證書作為參數(shù)，使用 curl 訪問 api server，并得到預(yù)期結(jié)果。

# 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"
    }
  ]
}

網(wǎng)站名稱：客戶端怎樣通過Kubernetes集群APIServer認(rèn)證？
轉(zhuǎn)載注明：http://muchs.cn/article38/ippesp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、云服務(wù)器、App開發(fā)、關(guān)鍵詞優(yōu)化、做網(wǎng)站、微信公眾號(hào)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)