說明

一個典型的 kubeconfig 文件如下：

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: {BASE64 STRING}
    server: https://172.16.16.15:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: ingress-nginx
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: {BASE64 STRING}
    client-key-data: {BASE64 STRING}

文件的主要部分為：clusters、contexts、users 字段

備注：

1. 這里客戶端表示為 kubeclt、client-go sdk 等，服務端表示為 apiserver

2. 證書可以理解為簽發方信息、擁有者信息、公鑰以及簽名（由簽發方私鑰簽名，因此簽發者背書）的集合

3. 消息發送方使用證書里面的公鑰對消息加密，消息接受方使用自己的私鑰解密

4. 單向驗證過程如下，雙向驗證即是指客戶端和服務端同時作為消息發送方和接收方，利用對方的證書加密消息

以 kubectl 為客戶端時為例

cluser 字段

name 集群名稱

certificate-authority-data 表示服務端的 CA 證書，base64 編碼，用于驗證服務端證書 apiserver.crt 的正確性

1. 當 kubectl 發送消息給 apiserver 時，apiserver 先返回 master 節點上的 /etc/kubernetes/pki/apiserver.crt 服務端證書給 kubectl
2. kubectl 校驗 apiserver.crt 的正確性，會獲取 apiserver.crt 中的 Issuer CA，發現 CA 的 CN 是 Kubernetes
3. certificate-authority-data 證書的 CN 也是 Kubernetes，利用  certificate-authority-data 對 apiserver.crt 驗證通過
4. kubectl 通過 apiserver.crt 對發送給 apiserver 的消息加密發送，apiserver 收到消息通過 /etc/kubernetes/pki/apiserver.key 解密消息　　

certificate-authority-data 字段表示的證書其實和 /etc/kubernetes/pki/ca.crt 內容都是一樣的，這個證書時整個集群的 rootCA，其他證書都是由其簽發，也就用它來驗證有效性

當 kubectl 開啟 --insecure-skip-tls-verify=true 時，表示不校驗服務端證書，隨意這個時候 certificate-authority-data 即使證書是錯誤的，也可以和集群通信

user 字段

name 用戶名稱

client-certificate-data 表示客戶端證書，base64 編碼，會發送給 apiserver，用于加密 apiserver 發送給 kubectl 的消息

client-key-data 表示客戶端私鑰，用于解密 apiserver 通過 client-certificate-data 加密過的內容

整個加解密過程和上述服務端驗證過程類似

各證書作用總結

context 字段 

cluster 和 user 可以配置多個，context 用于組合 cluster 和 user，并通過 current-context 指定當前要使用的 context

其他

如何查看某個證書的簽發者 CA、允許的 DNS 域名、過期時間等信息？

openssl x509 -in client.crt -noout -text

kubeconfig 中為什么可以通過客戶端證書來表示一個用戶？

如上面通過 openssl 解析證書文件，可以看到證書的擁有者 Subject 主體信息，這里面的 O = system:masters, CN = kubernetes-admin 分別表示 group 和 user
因此 kubeconfig 中的 client 證書不僅可以用于加密服務端發送的信息，也可以表示一個具體的用戶，apiserver 會通過證書中的 group/user 查看

關聯的 role/clusterrole、rolebinding/clusterrolebinding 資源判斷權限信息

當然，也可以用 serviceaccount 的 token 來認證和鑒權，token 最終也是集群的 rootCA 簽發，同樣包含用戶信息
 

root@k8s-master:~/.kube# kc get clusterrolebinding cluster-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

參考：

k8s rbac 實踐：http://www.rzrgm.cn/orchidzjl/p/11103433.html

非對稱加密過程：http://www.rzrgm.cn/orchidzjl/p/12125621.html

證書解析：https://blog.csdn.net/mayi_xiaochaun/article/details/106433764