[kubernete] 證書詳細總結

原創 小墨鱼~~ 2019-09-26 17:30

目錄

 

一 證書簡介

二 證書類型分類

三  證書說明

四 TLS bootstrapping 簡化kubelet證書製作

五 證書製作步驟

1  創建CA證書

2 創建K8S證書

2.1. 創建kubernetes證書

2.2 創建kube-controller-manager證書

2.3 創建kube-scheduler證書 

3 創建ADMIN證書

4 創建ETCD證書

6 查看證書信息： 

 

一 證書簡介

服務端保留公鑰和私鑰，客戶端使用root CA認證服務端的公鑰

一共有多少證書：

Etcd：

1、Etcd對外提供服務，要有一套etcd server證書

2、Etcd各節點之間進行通信，要有一套etcd peer證書

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

kubernetes：

4、Kube-APIserver對外提供服務，要有一套kube-apiserver server證書

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

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

7、kubelet對外提供服務，要有一套kubelet server證書

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

 

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

同一個套內的證書必須是用同一個CA簽署的，簽署不同套裏的證書的CA可以相同，也可以不同。例如，所有etcd server證書需要是同一個CA簽署的，所有的etcd peer證書也需要是同一個CA簽署的，而一個etcd server證書和一個etcd peer證書，完全可以是兩個CA機構簽署的，彼此沒有任何關係。這算兩套證書。

爲什麼同一個“套”內的證書必須是同一個CA簽署的

原因在驗證這些證書的一端。因爲在要驗證這些證書的一端，通常只能指定一個Root CA。這樣一來，被驗證的證書自然都需要是被這同一個Root CA對應的私鑰簽署，不然不能通過認證。

實際上，使用一套證書（都使用一套CA來簽署）一樣可以搭建出K8S，一樣可以上生產，但是理清這些證書的關係，在遇到因爲證書錯誤，請求被拒絕的現象的時候，不至於無從下手，而且如果沒有搞清證書之間的關係，在維護或者解決問題的時候，貿然更換了證書，弄不好會把整個系統搞癱。

kubelet證書爲何不同

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

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

客戶端證書也不應相同，每個kubelet的認證證書與所在機器的IP綁定後，可以防止一個kubelet的認證證書泄露以後，使從另外的機器上僞造的請求通過驗證。

安全方面，如果每個node上保留了用於簽署證書的bootstrap token，那麼bootstrap token泄漏以後，是不是可以隨意簽署證書了？安全隱患非常大。所以，kubelet啓動成功以後，本地的bootstrap token需要被刪除。

 

二 證書類型分類

kubernetes的證書類型主要分爲3類：

  • serving CA: 用於簽署serving證書，該證書用於加密https通信。用於簽署kubernetes API serving證書的CA也可以用於簽署API server插件的serving證書，可能會用到不同的CA
  • client CA: 用於簽署客戶端證書，同時也被API server插件用來對客戶端發來的證書進行認證。用於簽署kubernetes API serving證書的client CA也可以用於簽署API server插件的serving證書，可能會用到不同的CA
  • RequestHeader client CA: 該CA用於簽署API server代理客戶端證書，擁有代理證書的客戶端可以有效地僞裝成任何身份。當運行在aggregator之後時，該CA必須與前述aggregator代理客戶端證書的CA一致

三  證書說明

serving 證書：
--tls-cert-file和--tls-private-key-file，API server用這兩個選項來認證連接到自己的TLS。這兩個證書也是CA(可以是自籤CA)簽署的。由於客戶端節點可能會拒絕自籤CA，因此需要將該CA分發給客戶端節點，並在客戶端指定該CA。如下kubelet的kubeconfig中的certificate-authority就指定了用於認證tls證書的CA。--tls-cert-file中需要有server字段的名稱。API server和kubelet(當需要認證到kubelet的請求時)都有這兩個選項，工作原理一樣。

current-context: my-context
apiVersion: v1
clusters:
- cluster:
certificate-authority: /path/to/my/ca.crt # CERTIFICATE AUTHORITY THAT ISSUED YOUR TLS CERT
server: https://horse.org:4443 # this name needs to be on the certificate in --tls-cert-file
name: my-cluster
kind: Config
users:
- name: green-user
user:
client-certificate: path/to/my/client/cert
client-key: path/to/my/client/key

 

client 證書

--client-ca-file：任何帶有 client-ca-file 簽名的客戶端證書的請求，都將通過客戶端證書中 Common Name 對應的標識進行身份認證，證書中的 Common Name 會作爲用戶名，Organization作爲組來使用。默認情況下，API Server使用該選項會自動創建一個名爲extension-apiserver-authentication，位於kube-system命名空間的ConfigMap ，該ConfigMap 中包含了--client-ca-file指定的CA。
API server的--kubelet-certificate-authority、--kubelet-client-certificate、--kubelet-client-key 和kubelet的--client-ca-file爲一組選項，用於對kubelet進行認證(kubelet 組件在工作時，採用主動的查詢機制，即定期請求 apiserver 獲取自己所應當處理的任務)



RequestHeader client CA 證書
主要涉及3個選項--requestheader-client-ca-file、--proxy-client-cert-file、--proxy-client-key-file。代理(如aggregator)使用--proxy-client-cert-file、--proxy-client-key-file來請求API Server，API Server使用--requestheader-client-ca-file指定的證書來認證代理的證書。這三個選項都設置在API server的flag中，即aggregator一方面作爲API server認證來自client的證書，一方面作爲client，使用自身的代理證書向API server請求認證。
當kubernetes對應的客戶端證書中的usernames和group與自己需求不符合時(無法認證或權限不足等)，可以使用認證代理(代理使用另一套證書請求API server)

可以看到serving證書是通過TLS來進行認證，client證書通過用戶名(Common Name)和組(Organization)進行認證；RequestHeader client證書認證方式與client證書認證方式類似

 

證書的驗證：

顯示插件API server支持的證書：openssl s_client -connect <service-cluster-ip>:443更多

驗證證書是否由CA簽署：openssl verify -CAfile ca.crt   the-certificate.crt

更多參見Certificate Issues

 

四 TLS bootstrapping 簡化kubelet證書製作

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

官網地址：https://kubernetes.io/docs/tasks/tls/certificate-rotation/

每個kubelet用到的證書都是獨一無二的，因爲它要綁定各自的IP地址，於是需要給每個kubelet單獨製作證書，如果業務量很大的情況下，node節點會很多，這樣一來kubelet的數量也隨之增加，而且還會經常變動（增減Node）kubelet的證書製作就成爲一件很麻煩的事情。使用TLS bootstrapping就可以省事兒很多。

工作原理：Kubelet第一次啓動的時候，先用同一個bootstrap token作爲憑證。這個token已經被提前設置爲隸屬於用戶組system：bootstrappers，並且這個用戶組的權限也被限定爲只能用來申請證書。 用這個bootstrap token通過認證後，kubelet申請到屬於自己的兩套證書（kubelet server、kube-apiserver client for kubelet），申請成功後，再用屬於自己的證書做認證，從而擁有了kubelet應有的權限。這樣一來，就去掉了手動爲每個kubelet準備證書的過程，並且kubelet的證書還可以自動輪替更新

參考文檔：

Kubernetes TLS bootstrapping 那點事

 

五 證書製作步驟

1  創建CA證書

創建證書配置文件 mkdir ca; cd ca;

vim ca-config.json

{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "etcd": {
         "expiry": "87600h",
         "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ]
      },
      "kubernetes": {
         "expiry": "87600h",
         "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ]
      }
    }
  }
}

字段說明：

ca-config.json：可以定義多個 profiles，分別指定不同的過期時間、使用場景等參數；後續在簽名證書時使用某個 profile；

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

server auth：表示client可以用該 CA 對server提供的證書進行驗證；

client auth：表示server可以用該CA對client提供的證書進行驗證；

expiry：過期時間

創建CA證書籤名請求文件

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 從證書中提取作爲請求的用戶名 (User Name)；瀏覽器使用該字段驗證網站是否合法；

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

生成CA證書和私鑰

cfssl gencert -initca ca-csr.json | cfssljson -bare ca

ls -al | grep ca

-rw-r--r-- 1 root root  487 Jun 26 11:20 ca-config.json
-rw-r--r-- 1 root root 1001 Jun 26 11:20 ca.csr
-rw-r--r-- 1 root root  264 Jun 26 11:20 ca-csr.json
-rw------- 1 root root 1675 Jun 26 11:20 ca-key.pem
-rw-r--r-- 1 root root 1359 Jun 26 11:20 ca.pem

其中ca-key.pem是ca的私鑰，ca.csr是一個簽署請求，ca.pem是CA證書，是後面kubernetes組件會用到的RootCA。

 

2 創建K8S證書

在創建這個證書之前，先規劃一下架構

k8s-master1  10.211.55.11

etcd01          10.211.55.11

2.1. 創建kubernetes證書

創建kubernetes證書籤名請求文件  mkdir kubernetes; cd kubernetes;

vim kubernetes-csr.json

{
    "CN": "kubernetes",
    "hosts": [
      "127.0.0.1",
      "10.254.0.1"
      "10.211.55.11",
      "kubernetes",
      "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 字段不爲空則需要指定授權使用該證書的 IP 或域名列表。

由於該證書後續被 kubernetes master 集羣使用，將master節點的IP都填上（如有多個），同時還有service網絡的首IP。(一般是 kube-apiserver 指定的 service-cluster-ip-range 網段的第一個IP，如 10.254.0.1)

生成kubernetes證書和私鑰

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes

ls |grep kubernetes

kubernetes.csr
kubernetes-csr.json
kubernetes-key.pem
kubernetes.pem

2.2 創建kube-controller-manager證書

創建 kube-controller-manager 證書籤名請求文件  

vim kube-controller-manager-csr.json

{
    "CN": "system:kube-controller-manager",
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "hosts": [
      "127.0.0.1",
      "10.211.55.11"
    ],
    "names": [
      {
        "C": "CN",
        "ST": "BeiJing",
        "L": "BeiJing",
        "O": "system:kube-controller-manager",
        "OU": "system"
      }
    ]
}

說明：

hosts 列表包含所有 kube-controller-manager 節點 IP；

CN 爲 system:kube-controller-manager、O 爲 system:kube-controller-manager，kubernetes 內置的 ClusterRoleBindings system:kube-controller-manager 賦予 kube-controller-manager 工作所需的權限

生成kube-controoller-manager證書和私鑰

cfssl gencert -ca=../ca/ca.pem -ca-key=../ca/ca-key.pem -config=../ca/ca-config.json -profile=kubernetes kube-controller-manager-csr.json | cfssljson -bare kube-controller-manager 

ls |grep kube-controller-manager 

kube-controller-manager.csr
kube-controller-manager-csr.json
kube-controller-manager-key.pem
kube-controller-manager.pem

2.3 創建kube-scheduler證書 

 創建 kube-scheduler 證書籤名請求文件

vim kube-scheduler-csr.json 

{
    "CN": "system:kube-scheduler",
    "hosts": [
      "127.0.0.1",
      "10.211.55.11"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
      {
        "C": "CN",
        "ST": "BeiJing",
        "L": "BeiJing",
        "O": "system:kube-scheduler",
        "OU": "System"
      }
    ]
}

 

說明：

hosts 列表包含所有 kube-scheduler 節點 IP；

CN 爲 system:kube-scheduler、O 爲 system:kube-scheduler，kubernetes 內置的 ClusterRoleBindings system:kube-scheduler 將賦予 kube-scheduler 工作所需的權限。

 

經過上述操作，我們會用到如下文件

cfssl gencert -ca=../ca/ca.pem -ca-key=../ca/ca-key.pem -config=../ca/ca-config.json -profile=kubernetes kube-scheduler-csr.json| cfssljson -bare kube-scheduler

ls | grep kube-scheduler

kube-scheduler.csr
kube-scheduler-csr.json
kube-scheduler-key.pem
kube-scheduler.pem

3 創建ADMIN證書

創建admin證書籤名請求文件  mkdir admin ; cd admin

 vim admin-csr.json

{
  "CN": "admin",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "BeiJing",
      "L": "BeiJing",
      "O": "system:masters",
      "OU": "System"
    }
  ]
}

 

說明：

後續 kube-apiserver 使用 RBAC 對客戶端(如 kubelet、kube-proxy、Pod)請求進行授權；

kube-apiserver 預定義了一些 RBAC 使用的 RoleBindings，如 cluster-admin 將 Group system:masters 與 Role cluster-admin 綁定，該 Role 授予了調用kube-apiserver 的所有 API的權限；

O指定該證書的 Group 爲 system:masters，kubelet 使用該證書訪問 kube-apiserver 時 ，由於證書被 CA 簽名，所以認證通過，同時由於證書用戶組爲經過預授權的 system:masters，所以被授予訪問所有 API 的權限；

注：這個admin 證書，是將來生成管理員用的kube config 配置文件用的，現在我們一般建議使用RBAC 來對kubernetes 進行角色權限控制， kubernetes 將證書中的CN 字段 作爲User， O 字段作爲 Group

相關權限認證可以參考下面文章

https://mp.weixin.qq.com/s/XIkQdh5gnr-KJhuFHboNag

生成admin證書和私鑰

cfssl gencert -ca=../ca/ca.pem -ca-key=../ca/ca-key.pem -config=../ca/ca-config.json -profile=kubernetes admin-csr.json | cfssljson -bare admin

ls | grep admin

admin.csr
admin-csr.json
admin-key.pem
admin.pem

4 創建ETCD證書

創建etcd證書籤名請求文件 

vim etcd-csr.json

{
    "CN": "etcd",
    "hosts": [
      "127.0.0.1",
      "10.211.55.11"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "BeiJing",
            "L": "BeiJing"    
        }
    ]
}

字段說明：

如果 hosts 字段不爲空則需要指定授權使用該證書的 IP 或域名列表。該證書後續被 etcd 集羣使用

生成kubernetes證書和私鑰

cfssl gencert -ca=../ca/ca.pem -ca-key=../ca/ca-key.pem -config=../ca/ca-config.json -profile=etcd etcd-csr.json | cfssljson -bare etcd

ls |grep etcd

etcd.csr
etcd-csr.json
etcd-key.pem
etcd.pem

 

6 查看證書信息： 

cfssl-certinfo -cert kubernetes.pem

在搭建k8s集羣的時候，將這些文件分發到至此集羣中其他節點機器中即可。至此，TLS證書創建完畢

admin:
total 24
drwxr-xr-x 2 root root 4096 Sep 24 12:44 .
drwxr-xr-x 6 root root 4096 Sep 24 12:44 ..
-rw-r--r-- 1 root root 1009 Sep 24 12:15 admin.csr
-rw-r--r-- 1 root root  229 Sep 24 12:14 admin-csr.json
-rw------- 1 root root 1679 Sep 24 12:15 admin-key.pem
-rw-r--r-- 1 root root 1399 Sep 24 12:15 admin.pem

ca:
total 28
drwxr-xr-x 2 root root 4096 Sep 24 12:01 .
drwxr-xr-x 6 root root 4096 Sep 24 12:44 ..
-rw-r--r-- 1 root root  487 Sep 24 12:01 ca-config.json
-rw-r--r-- 1 root root 1001 Sep 24 12:01 ca.csr
-rw-r--r-- 1 root root  309 Sep 24 11:58 ca-csr.json
-rw------- 1 root root 1679 Sep 24 12:01 ca-key.pem
-rw-r--r-- 1 root root 1359 Sep 24 12:01 ca.pem

etcd:
total 24
drwxr-xr-x 2 root root 4096 Sep 24 12:24 .
drwxr-xr-x 6 root root 4096 Sep 24 12:44 ..
-rw-r--r-- 1 root root 1005 Sep 24 12:24 etcd.csr
-rw-r--r-- 1 root root  272 Sep 24 12:23 etcd-csr.json
-rw------- 1 root root 1675 Sep 24 12:24 etcd-key.pem
-rw-r--r-- 1 root root 1375 Sep 24 12:24 etcd.pem

kubernetes:
total 56
drwxr-xr-x 2 root root 4096 Sep 24 12:44 .
drwxr-xr-x 6 root root 4096 Sep 24 12:44 ..
-rw-r--r-- 1 root root 1119 Sep 24 12:11 kube-controller-manager.csr
-rw-r--r-- 1 root root  350 Sep 24 12:11 kube-controller-manager-csr.json
-rw------- 1 root root 1675 Sep 24 12:11 kube-controller-manager-key.pem
-rw-r--r-- 1 root root 1493 Sep 24 12:11 kube-controller-manager.pem
-rw-r--r-- 1 root root 1245 Sep 24 12:02 kubernetes.csr
-rw-r--r-- 1 root root  512 Sep 24 12:02 kubernetes-csr.json
-rw------- 1 root root 1679 Sep 24 12:02 kubernetes-key.pem
-rw-r--r-- 1 root root 1610 Sep 24 12:02 kubernetes.pem
-rw-r--r-- 1 root root 1094 Sep 24 12:13 kube-scheduler.csr
-rw-r--r-- 1 root root  331 Sep 24 12:12 kube-scheduler-csr.json
-rw------- 1 root root 1675 Sep 24 12:13 kube-scheduler-key.pem
-rw-r--r-- 1 root root 1468 Sep 24 12:13 kube-scheduler.pem

參考

Kubernetes 的證書認證

k8s學習筆記-證書詳解

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

Eclipse上Hadoop開發環境搭建

1      安裝插件     hadoop-eclipse-plugin-xxx.jar 2      插件配置 2.1    配置Hadoop Installation Directory        配置首選項裏的Map/Redu

yanhang0610 2020-07-06 11:16:17

Eclipse上Spark開發環境搭建

1     安裝插件     http://scala-ide.org/download/current.html 2     配置 2.1    配置Hadoop環境變量     HADOOP_HOME：%HADOOP_HOME%\bi

yanhang0610 2020-07-06 11:16:17

[kubernetes] 證書詳細總結

目錄   一 證書簡介 二 證書類型分類 三  證書說明 四 TLS bootstrapping 簡化kubelet證書製作 五 證書製作步驟 1  創建CA證書 2 創建K8S證書 2.1. 創建kubernetes證書 2.2 創建k

曾先森~~ 2020-06-20 17:44:45

[kubernetes] 常用命令總結

1.1 Common Commands Name Command Run curl test temporarily kubectl run --rm mytest --image=yauritux/busybox-curl -it Ru

曾先森~~ 2020-06-20 10:36:19

[HIVE] shell調用hive客戶端導致nohup後臺進程stopped

nohup啓動java進程調用shell執行hive客戶端命令導致nohup進程stopped，java進程消失了。 環境變量增加如下之後解決。 export HADOOP_CLIENT_OPTS="$HADOOP_CLIENT_OPTS

曾先森~~ 2020-06-16 15:49:26

楊明川：中國電信燈塔大數據應用實踐

來源：數據觀 時間：2016-09-05 11:05:27 作者：燈塔大數據 2016年9月4日，CDAS2016第三屆中國數據分析師行業峯會在北京國際會議中心成功舉辦，中國電信雲計算重點實驗室執行副主任楊明川主任，在峯會上做了題爲

Arlight 2020-06-16 11:24:45

大數據架構和模式（四）瞭解用於大數據解決方案的原子模式和複合模式

作者: Divakar等  來源: DeveloperWorks     原文鏈接  摘要：本文中介紹的模式有助於定義大數據解決方案的參數。本文將介紹最常見的和經常發生的大數據問題以及它們的解決方案。原子模式描述了使用、處理、訪問和存

Arlight 2020-06-16 11:24:45

未來的容器雲技術棧會怎麼樣？

摘要: @Container大會是由國內容器社區DockOne組織的專爲一線開發者和運維工程師設計的頂級容器技術會議。今天有1200多位小夥伴頂着北京的寒冬來到現場。這是我在這個大會上的演講。 @Container大會是由國內容器社

Arlight 2020-06-16 11:24:45

zookeeper啓動失敗的可能情況

最近開始實踐搭建基於vm虛擬機的集羣環境，學習大數據相關知識。 在搭建zookeeper的時候，出現啓動失敗的情況，如下是遇到及解決的三個問題 當我們啓動之後,查看狀態 [root@centos06 ~]# bin/zkServer.s

Enigma_zy 2020-06-16 01:59:24

vxlan報文和基本組網

1. 爲什麼需要Vxlan 　　普通的VLAN數量只有4096個，無法滿足大規模雲計算IDC的需求，而IDC爲何需求那麼多VLAN呢，因爲目前大部分IDC內部結構主要分爲兩種L2，L3。L2結構裏面，所有的服務器都在一個大的局域網裏面

Enigma_zy 2020-06-16 01:59:24

【MapReduce】MapReduce(DataJoin)實現數據連接+Bloom Filter優化

數據： file1：categoryname addressID Beijing Red Star 1 Shenzhen Thunder 3 Guangzhou Honda 2 Beijing Rising 1 Guang

_奶酪 2020-06-11 11:21:46

sqoop實例操作及詳細參數解析

Saint-at-home 2020-06-02 20:09:19

記一次實際sqoop業務的理解（註釋多）

Saint-at-home 2020-06-02 20:09:19

python3操作HDFS

Saint-at-home 2020-06-02 20:09:19

python版MR任務完整過程（附代碼）

Saint-at-home 2020-06-02 20:09:19