Kubernetes之二進(jìn)制安裝(二)證書詳解-創(chuàng)新互聯(lián)

前言

10年積累的成都網(wǎng)站建設(shè)、網(wǎng)站制作經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有沙市免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

在進(jìn)行二進(jìn)制搭建K8S集群前，我們需要梳理通最磨人的一個(gè)點(diǎn)，就是各種各樣的證書機(jī)制。這一步是在安裝配置kubernetes的所有步驟中最容易出錯(cuò)也是最難排查問題的一步，而這卻剛好是第一步，萬事開頭難，不要因?yàn)檫@點(diǎn)困難就望而卻步。

一共有多少證書？

官方文檔參考：https://kubernetes.io/docs/setup/certificates/

先從Etcd算起：

1、Etcd對(duì)外提供服務(wù)，要有一套etcd?server證書

2、Etcd各節(jié)點(diǎn)之間進(jìn)行通信，要有一套etcd?peer證書

3、Kube-APIserver訪問Etcd，要有一套etcd?client證書

再算kubernetes：

4、Kube-APIserver對(duì)外提供服務(wù)，要有一套kube-apiserver?server證書

5、kube-scheduler、kube-controller-manager、kube-proxy、kubelet和其他可能用到的組件，需要訪問kube-APIserver，要有一套kube-APIserver?client證書

6、kube-controller-manager要生成服務(wù)的service?account，要有一對(duì)用來簽署service?account的證書(CA證書)

7、kubelet對(duì)外提供服務(wù)，要有一套kubelet?server證書

8、kube-APIserver需要訪問kubelet，要有一套kubelet?client證書

加起來共8套，但是這里的“套”的含義我們需要理解。

同一個(gè)套內(nèi)的證書必須是用同一個(gè)CA簽署的，簽署不同套里的證書的CA可以相同，也可以不同。例如，所有etcd server證書需要是同一個(gè)CA簽署的，所有的etcd peer證書也需要是同一個(gè)CA簽署的，而一個(gè)etcd server證書和一個(gè)etcd peer證書，完全可以是兩個(gè)CA機(jī)構(gòu)簽署的，彼此沒有任何關(guān)系。這算兩套證書。

為什么同一個(gè)“套”內(nèi)的證書必須是同一個(gè)CA簽署的

原因在驗(yàn)證這些證書的一端。因?yàn)樵谝?yàn)證這些證書的一端，通常只能指定一個(gè)Root CA。這樣一來，被驗(yàn)證的證書自然都需要是被這同一個(gè)Root CA對(duì)應(yīng)的私鑰簽署，不然不能通過認(rèn)證。

其實(shí)實(shí)際上，使用一套證書（都使用一套CA來簽署）一樣可以搭建出K8S，一樣可以上生產(chǎn)，但是理清這些證書的關(guān)系，在遇到因?yàn)樽C書錯(cuò)誤，請(qǐng)求被拒絕的現(xiàn)象的時(shí)候，不至于無從下手，而且如果沒有搞清證書之間的關(guān)系，在維護(hù)或者解決問題的時(shí)候，貿(mào)然更換了證書，弄不好會(huì)把整個(gè)系統(tǒng)搞癱。

TLS?bootstrapping?簡(jiǎn)化kubelet證書制作

Kubernetes1.4版本引入了一組簽署證書用的API。這組API的引入，使我們可以不用提前準(zhǔn)備kubelet用到的證書。

每個(gè)kubelet用到的證書都是獨(dú)一無二的，因?yàn)樗壎ǜ髯缘腎P地址，于是需要給每個(gè)kubelet單獨(dú)制作證書，如果業(yè)務(wù)量很大的情況下，node節(jié)點(diǎn)會(huì)很多，這樣一來kubelet的數(shù)量也隨之增加，而且還會(huì)經(jīng)常變動(dòng)（增減Node）kubelet的證書制作就成為一件很麻煩的事情。使用TLS bootstrapping就可以省事兒很多。

工作原理：Kubelet第一次啟動(dòng)的時(shí)候，先用同一個(gè)bootstrap token作為憑證。這個(gè)token已經(jīng)被提前設(shè)置為隸屬于用戶組system：bootstrappers，并且這個(gè)用戶組的權(quán)限也被限定為只能用來申請(qǐng)證書。 用這個(gè)bootstrap token通過認(rèn)證后，kubelet申請(qǐng)到屬于自己的兩套證書（kubelet server、kube-apiserver client for kubelet），申請(qǐng)成功后，再用屬于自己的證書做認(rèn)證，從而擁有了kubelet應(yīng)有的權(quán)限。這樣一來，就去掉了手動(dòng)為每個(gè)kubelet準(zhǔn)備證書的過程，并且kubelet的證書還可以自動(dòng)輪替更新

官方文檔參考：https://kubernetes.io/docs/tasks/tls/certificate-rotation/

kubelet證書為何不同

這樣做是一個(gè)為了審計(jì)，另一個(gè)為了安全。 每個(gè)kubelet既是服務(wù)端（kube-apiserver需要訪問kubelet），也是客戶端（kubelet需要訪問kube-apiserver），所以要有服務(wù)端和客戶端兩組證書。

服務(wù)端證書需要與服務(wù)器地址綁定，每個(gè)kubelet的地址都不相同，即使綁定域名也是綁定不同的域名，故服務(wù)端地址不同

客戶端證書也不應(yīng)相同，每個(gè)kubelet的認(rèn)證證書與所在機(jī)器的IP綁定后，可以防止一個(gè)kubelet的認(rèn)證證書泄露以后，使從另外的機(jī)器上偽造的請(qǐng)求通過驗(yàn)證。

安全方面，如果每個(gè)node上保留了用于簽署證書的bootstrap token，那么bootstrap token泄漏以后，是不是可以隨意簽署證書了？安全隱患非常大。所以，kubelet啟動(dòng)成功以后，本地的bootstrap token需要被刪除。

正式制作證書

雖然可以用多套證書，但是維護(hù)多套CA實(shí)在過于繁雜，這里還是用一個(gè)CA簽署所有證書。

需要準(zhǔn)備的證書：

• admin-key.pem

• admin.pem

• ca-key.pem

• ca.pem

• kube-proxy-key.pem

• kube-proxy.pem

• kubernetes-key.pem

• kubernetes.pem

使用證書的組件如下：

• etcd：使用 ca.pem、kubernetes-key.pem、kubernetes.pem

• kube-apiserver：使用 ca.pem、kubernetes-key.pem、kubernetes.pem

• kubelet：使用 ca.pem

• kube-proxy：使用 ca.pem、kube-proxy-key.pem、kube-proxy.pem

• kubectl：使用 ca.pem、admin-key.pem、admin.pem

• kube-controller-manager：使用 ca-key.pem、ca.pem

我們使用CFSSL來制作證書，它是cloudflare開發(fā)的一個(gè)開源的PKI工具，是一個(gè)完備的CA服務(wù)系統(tǒng)，可以簽署、撤銷證書等，覆蓋了一個(gè)證書的整個(gè)生命周期，后面只用到了它的命令行工具。

注：一般情況下，K8S中證書只需要?jiǎng)?chuàng)建一次，以后在向集群中添加新節(jié)點(diǎn)時(shí)只要將/etc/kubernetes/ssl目錄下的證書拷貝到新節(jié)點(diǎn)上即可。

下載安裝cfssl命令行工具

[root@dong?bin]#?mkdir?-p?/usr/local/bin/cfssl [root@dong?bin]#?wget?https://pkg.cfssl.org/R1.2/cfssl_linux-amd64? [root@dong?bin]#?wget?https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64? [root@dong?bin]#?wget?https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64? [root@dong?bin]#?chmod?+x?cfssl* [root@dong?bin]#?mv?cfssl_linux-amd64?/usr/local/bin/cfssl [root@dong?bin]#?mv?cfssljson_linux-amd64?/usr/local/bin/cfssljson [root@dong?bin]#?mv?cfssl-certinfo_linux-amd64?/usr/local/bin/cfssl-certinfo [root@dong?bin]#?export?PATH=/usr/local/bin:$PATH

創(chuàng)建CA證書

創(chuàng)建存放證書目錄

[root@dong?bin]#?mkdir?-p?/opt/kubernetes/ssl/ [root@dong?bin]#?cd?/opt/kubernetes/ssl/

創(chuàng)建證書配置文件

[root@dong?ssl]#?vim?ca-config.json { ??"signing":?{ ????"default":?{ ??????"expiry":?"87600h" ????}, ????"profiles":?{ ??????"kubernetes":?{ ????????"usages":?[ ????????????"signing", ????????????"key?encipherment", ????????????"server?auth", ????????????"client?auth" ????????], ????????"expiry":?"87600h" ??????} ????} ??} }

字段說明：

ca-config.json：可以定義多個(gè) profiles，分別指定不同的過期時(shí)間、使用場(chǎng)景等參數(shù)；后續(xù)在簽名證書時(shí)使用某個(gè) profile；

signing：表示該證書可以簽名其他證書；生成的ca.pem證書中 CA=TRUE；

server auth：表示client可以用該 CA 對(duì)server提供的證書進(jìn)行驗(yàn)證；

client auth：表示server可以用該CA對(duì)client提供的證書進(jìn)行驗(yàn)證；

expiry：過期時(shí)間

創(chuàng)建CA證書簽名請(qǐng)求文件

[root@dong?ssl]#?vim?ca-csr.json { ??"CN":?"kubernetes", ??"key":?{ ????"algo":?"rsa", ????"size":?2048 ??}, ??"names":?[ ????{ ??????"C":?"CN", ??????"ST":?"BeiJing", ??????"L":?"BeiJing", ??????"O":?"k8s", ??????"OU":?"System" ????} ??], ????"ca":?{ ???????"expiry":?"87600h" ????} }

字段說明：

“CN”：Common Name，kube-apiserver 從證書中提取該字段作為請(qǐng)求的用戶名 (User Name)；瀏覽器使用該字段驗(yàn)證網(wǎng)站是否合法；

“O”：Organization，kube-apiserver 從證書中提取該字段作為請(qǐng)求用戶所屬的組 (Group)；

生成CA證書和私鑰

[root@dong?ssl]#?cfssl?gencert?-initca?ca-csr.json?|?cfssljson?-bare?ca [root@dong?ssl]#?ls?|?grep?ca ca-config.json ca.csr ca-csr.json ca-key.pem ca.pem

其中ca-key.pem是ca的私鑰，ca.csr是一個(gè)簽署請(qǐng)求，ca.pem是CA證書，是后面kubernetes組件會(huì)用到的RootCA。

創(chuàng)建kubernetes證書

創(chuàng)建kubernetes證書簽名請(qǐng)求文件?kubernetes-csr.json

[root@dong?ssl]#?vim?kubernetes-csr.json { ????"CN":?"kubernetes", ????"hosts":?[ ??????"127.0.0.1", ??????"192.168.214.88", ??????"192.168.214.89", ??????"192.168.214.90", ??????"192.168.214.200", ??????"192.168.214.201", ??????"192.168.214.202", ??????"10.254.0.1", ??????"192.168.214.210", ??????"192.168.214.1/24", ??????"kubernetes", ??????"kube-api.wangdong.com", ??????"kubernetes.default", ??????"kubernetes.default.svc", ??????"kubernetes.default.svc.cluster", ??????"kubernetes.default.svc.cluster.local" ????], ????"key":?{ ????????"algo":?"rsa", ????????"size":?2048 ????}, ????"names":?[ ????????{ ????????????"C":?"CN", ????????????"ST":?"BeiJing", ????????????"L":?"BeiJing", ????????????"O":?"k8s", ????????????"OU":?"System" ????????} ????] }

字段說明：

如果 hosts 字段不為空則需要指定授權(quán)使用該證書的 IP 或域名列表。

由于該證書后續(xù)被 etcd 集群和 kubernetes master使用，將etcd、master節(jié)點(diǎn)的IP都填上，同時(shí)還有service網(wǎng)絡(luò)的首IP。(一般是 kube-apiserver 指定的 service-cluster-ip-range 網(wǎng)段的第一個(gè)IP，如 10.254.0.1)

我這里的設(shè)置包括一個(gè)私有鏡像倉庫，三個(gè)etcd，三個(gè)master，以上物理節(jié)點(diǎn)的IP也可以更換為主機(jī)名。

生成kubernetes證書和私鑰

[root@dong?ssl]#?cfssl?gencert?-ca=ca.pem?-ca-key=ca-key.pem?-config=ca-config.json?-profile=kubernetes?kubernetes-csr.json?|?cfssljson?-bare?kubernetes [root@dong?ssl]#?ls?|grep?kubernetes kubernetes.csr kubernetes-csr.json kubernetes-key.pem kubernetes.pem

創(chuàng)建admin證書

創(chuàng)建admin證書簽名請(qǐng)求文件admin-csr.json

[root@dong?ssl]#?admin-csr.json { ??"CN":?"admin", ??"hosts":?[], ??"key":?{ ????"algo":?"rsa", ????"size":?2048 ??}, ??"names":?[ ????{ ??????"C":?"CN", ??????"ST":?"BeiJing", ??????"L":?"BeiJing", ??????"O":?"system:masters", ??????"OU":?"System" ????} ??] }

說明：

后續(xù) kube-apiserver 使用 RBAC 對(duì)客戶端(如 kubelet、kube-proxy、Pod)請(qǐng)求進(jìn)行授權(quán)；

kube-apiserver 預(yù)定義了一些 RBAC 使用的 RoleBindings，如 cluster-admin 將 Group system:masters 與 Role cluster-admin 綁定，該 Role 授予了調(diào)用kube-apiserver 的所有 API的權(quán)限；

O指定該證書的 Group 為 system:masters，kubelet 使用該證書訪問 kube-apiserver 時(shí) ，由于證書被 CA 簽名，所以認(rèn)證通過，同時(shí)由于證書用戶組為經(jīng)過預(yù)授權(quán)的 system:masters，所以被授予訪問所有 API 的權(quán)限；

注：這個(gè)admin 證書，是將來生成管理員用的kube config 配置文件用的，現(xiàn)在我們一般建議使用RBAC 來對(duì)kubernetes 進(jìn)行角色權(quán)限控制， kubernetes 將證書中的CN 字段 作為User， O 字段作為 Group

生成admin證書和私鑰

[root@dong?ssl]#?cfssl?gencert?-ca=ca.pem?-ca-key=ca-key.pem?-config=ca-config.json?-profile=kubernetes?admin-csr.json?|?cfssljson?-bare?admin [root@dong?ssl]#?ls?|?grep?admin admin.csr admin-csr.json admin-key.pem admin.pem

創(chuàng)建kube-proxy證書

創(chuàng)建 kube-proxy 證書簽名請(qǐng)求文件 kube-proxy-csr.json

[root@dong?ssl]#?vim?kube-proxy-csr.json { ??"CN":?"system:kube-proxy", ??"hosts":?[], ??"key":?{ ????"algo":?"rsa", ????"size":?2048 ??}, ??"names":?[ ????{ ??????"C":?"CN", ??????"ST":?"BeiJing", ??????"L":?"BeiJing", ??????"O":?"k8s", ??????"OU":?"System" ????} ??] }

說明：

CN 指定該證書的 User 為 system:kube-proxy；

kube-apiserver 預(yù)定義的 RoleBinding system:node-proxier 將User system:kube-proxy 與 Role system:node-proxier 綁定，該 Role 授予了調(diào)用 kube-apiserver Proxy 相關(guān) API 的權(quán)限；

生成kube-proxy證書和私鑰

[root@dong?ssl]#?cfssl?gencert?-ca=ca.pem?-ca-key=ca-key.pem?-config=ca-config.json?-profile=kubernetes??kube-proxy-csr.json?|?cfssljson?-bare?kube-proxy [root@dong?ssl]#?ls?|grep?kube-proxy kube-proxy.csr kube-proxy-csr.json kube-proxy-key.pem kube-proxy.pem

經(jīng)過上述操作，我們會(huì)用到如下文件：

[root@dong?ssl]#?ls?|?grep?pem admin-key.pem admin.pem ca-key.pem ca.pem kube-proxy-key.pem kube-proxy.pem kubernetes-key.pem kubernetes.pem

查看證書信息

[root@master1?ssl]#?cfssl-certinfo?-cert?kubernetes.pem { ??"subject":?{ ????"common_name":?"kubernetes", ????"country":?"CN", ????"organization":?"k8s", ????"organizational_unit":?"System", ????"locality":?"BeiJing", ????"province":?"BeiJing", ????"names":?[ ??????"CN", ??????"BeiJing", ??????"BeiJing", ??????"k8s", ??????"System", ??????"kubernetes" ????] ??}, ??"issuer":?{ ????"common_name":?"kubernetes", ????"country":?"CN", ????"organization":?"k8s", ????"organizational_unit":?"System", ????"locality":?"BeiJing", ????"province":?"BeiJing", ????"names":?[ ??????"CN", ??????"BeiJing", ??????"BeiJing", ??????"k8s", ??????"System", ??????"kubernetes" ????] ??}, ??"serial_number":?"321233745860282370502438768971300435157761820875", ??"sans":?[ ????"192.168.214.1/24", ????"kubernetes", ????"kube-api.wangdong.com", ????"kubernetes.default", ????"kubernetes.default.svc", ????"kubernetes.default.svc.cluster", ????"kubernetes.default.svc.cluster.local", ????"127.0.0.1", ????"192.168.214.88", ????"192.168.214.89", ????"192.168.214.90", ????"192.168.214.200", ????"192.168.214.201", ????"192.168.214.202", ????"10.254.0.1", ????"192.168.214.210" ??], ??"not_before":?"2019-03-12T11:26:00Z", ??"not_after":?"2029-03-09T11:26:00Z", ??"sigalg":?"SHA256WithRSA", ??"authority_key_id":?"CB:34:54:33:1F:F4:37:E:E5:94:B7:F5:8A:3D:F4:A4:43:43:E2:7F", ??"subject_key_id":?"EC:31:D8:5F:4:E3:6F:C2:7F:DA:A8:F0:BD:A:B9:1F:56:7B:9A:DF", ??"pem":?"-----BEGIN?CERTIFICATE-----\nMIIExjCCA66gAwIBAgIUOESejeFvtUe1qwPcXOQdC9a6iMswDQYJKoZIhvcNAQEL\nBQAwZTELMAkGA1UEBhMCQ04xEDAOBgNVBAgTB0JlaUppbmcxEDAOBgNVBAcTB0Jl\naUppbmcxDDAKBgNVBAoTA2s4czEPMA0GA1UECxMGU3lzdGVtMRMwEQYDVQQDEwpr\ndWJlcm5ldGVzMB4XDTE5MDMxMjExMjYwMFoXDTI5MDMwOTExMjYwMFowZTELMAkG\nA1UEBhMCQ04xEDAOBgNVBAgTB0JlaUppbmcxEDAOBgNVBAcTB0JlaUppbmcxDDAK\nBgNVBAoTA2s4czEPMA0GA1UECxMGU3lzdGVtMRMwEQYDVQQDEwprdWJlcm5ldGVz\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAteZIJbL5G2ZHEKajyVe7\nv4E1F9K9RzLTxghStRo808QOpVclOkFRHCi2qplrFrQmW4d/5AhJmofdoBuwIe/T\n3UgrhlPj1rWC5DhaG8J7+wOIp62yURslnXE+A+EsXQLXxeKxrbrodNwTmGJHXdGl\nv2pi0lyAgewdnhJHcYTvQbrDvbxpqYOHqKzJ3sqm1TSjnWSI9C1Hk/iF9xmjA4CG\nLDHocnxzNv+T/qSofv0yyGgA/HovlNxP+jSIwaWJu3QHhOxV3k2Bj7i0jSJoq3n9\nDl4co22Ge4SLiI2zPZayt9whzSyUoc5eloYJ1w7INcmfz2gOYl7L3godLg/gI5Eh\nNQIDAQABo4IBbDCCAWgwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF\nBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTsMdhfBONvwn/a\nqPC9CrkfVnua3zAfBgNVHSMEGDAWgBTLNFQzH/Q3DuWUt/WKPfSkQ0PifzCB6AYD\nVR0RBIHgMIHdghAxOTIuMTY4LjIxNC4xLzI0ggprdWJlcm5ldGVzghVrdWJlLWFw\naS53YW5nZG9uZy5jb22CEmt1YmVybmV0ZXMuZGVmYXVsdIIWa3ViZXJuZXRlcy5k\nZWZhdWx0LnN2Y4Iea3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVygiRrdWJl\ncm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWyHBH8AAAGHBMCo1liHBMCo\n1lmHBMCo1lqHBMCo1siHBMCo1smHBMCo1sqHBAr+AAGHBMCo1tIwDQYJKoZIhvcN\nAQELBQADggEBADtxejgpSQy913K9YyVLcS2k9bs41mZZbuokyrZiJeJ/CKZKzCo+\ngnF7P9/35IjkNlnYhlpUTTIJbnlQY8mDyKx1AaZOkzr+2djYRpg2vL3E7+CdRldQ\nUpNANSITolInKqboXev8SlLF9Mc/dWqgZzoifezuEkZ+c5KM6MY6MpMDVjVKNBxy\nJTd3bZNaPopop8IWxLAel5IQbzUhooswtzUxUslwKnYYC9tsKc5AgiXdehCnbGNf\nIr6wkK2OJBJStNPqarnpH6FZ6JxJ+qt59SdNhLixOT84HBR7ews/ZCYhQuPaJTy2\nwIb0XOtxILF3JMBNW/n21IyhF0vXsMdLg+o=\n-----END?CERTIFICATE-----\n" }

在搭建k8s集群的時(shí)候，將這些文件分發(fā)到至此集群中其他節(jié)點(diǎn)機(jī)器中即可。至此，TLS證書創(chuàng)建完畢。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)站題目：Kubernetes之二進(jìn)制安裝(二)證書詳解-創(chuàng)新互聯(lián)
轉(zhuǎn)載來源：http://bm7419.com/article46/dgdjhg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、營(yíng)銷型網(wǎng)站建設(shè)、虛擬主機(jī)、響應(yīng)式網(wǎng)站、網(wǎng)站維護(hù)、軟件開發(fā)

廣告

聲明：本網(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)