kubeconfig文件全解析

说明

一个典型的 kubeconfig 文件如下：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

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 域名、过期时间等信息？

?

1	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 签发，同样包含用户信息
 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

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 实践：https://www.cnblogs.com/orchidzjl/p/11103433.html

非对称加密过程：https://www.cnblogs.com/orchidzjl/p/12125621.html

证书解析：https://blog.csdn.net/mayi_xiaochaun/article/details/106433764