6.3 Bootstrap Tokens和tls Bootstrapping

什么是TLS Bootstrapping？

tls-bootstrapping主要用来为node节点生成证书。

为什么不手动为node生成证书呢？

因为node不像master节点那样固定，一个集群中可能会不断地添加、删除node节点，而tls证书使用主机的域名(CN)有关的，这就导致了证书的申请、签发不是很方便，于是就产生了tls-bootstrapping来自动为node节点签发证书。

基本原理？

kubelet在启动时，通过参数--bootstrap-kubeconfig=/etc/kubernetes/ssl/bootstrap-kubelet.kubeconfig --kubeconfig=/etc/kubernetes/ssl/kubelet.kubeconfig，先去查找--kubeconfig指定的文件，该文件用于kubelet与apiserver之间地认证。如果找不到该文件，则kubelet会先使用--bootstrap-kubeconfig指定的文件先向api-server自申请证书，使用申请的证书自动创建为--kubeconfig指定的文件。此后，就可以使用新申请的证书进行认证了。

kubelet启动过程

官方文档

1、查找kubeconfig文件。（位置由kubelet参数指定）

2、从kubeconfig文件中获取API-Server的URL和证书。

3、使用kubeconfig中的配置去和API-Server进行交互。

bootstrap初始化过程

官方文档

1、kubelet启动

2、kubelet发现没有kubeconfig文件

3、kubelet搜索并找到bootstrap-kubeconfig文件

4、kubelet读取bootstrap引导程序文件（bootstrap-kubeconfig），获取API-Server的URL和权限很小的“token”（该token只有申请证书的权限，点之前的部分是token-id，点之后的部分是token-secret）

5、kubelet连接到API-Server，使用token进行身份验证

apiserver会识别token-id，然后根据该tokenid去kube-system名称空间下查找bootstrap-token-${token-id}这个secret。
此后，apiserver会对比kubelet提供的token-secret与secret存储的token-secret是否一致，一致则通过验证。
验证通过后，apiserver从secret中获取auth-extra-groups的值，该值经过base64解密后，表示的是一个k8s中的组：system:bootstrappers:kubeadm:default-node-token。然后会动token识别成用户system:bootstrap:${token-id}，该用户属于system:bootstrappers:kubeadm:default-node-token组。该组具有申请CSR的权限，该组的权限绑定在名称为system:node-bootstrapper的clusterrole上。

➜  ~ kubectl get clusterrole system:node-bootstrapper -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:node-bootstrapper
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests   #CSR权限
  verbs:
  - create
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
 
#查看 clusterrolebinding
➜  ~ kubectl get clusterrolebinding|grep kubelet
kubeadm:kubelet-bootstrap                              ClusterRole/system:node-bootstrapper                                               170d
kubelet-node-binding                                   ClusterRole/system:node-proxier                                                    170d

# 发现把”system:node-bootstrapper“这个ClusterRole绑定到了”system:bootstrappers:kubeadm:default-node-token“这个组上
➜  ~ kubectl get clusterrolebinding kubeadm:kubelet-bootstrap -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
  name: kubeadm:kubelet-bootstrap
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:node-bootstrapper
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:bootstrappers:kubeadm:default-node-token

6、经过上面的认证，kubelet现在具有有限的凭据来创建和检索证书签名请求（CSR）

7、kubelet为自己创建一个CSR，并将signerName设置为kubernetes.io/kube-apiserver-client-kubelet

8、通过以下两种方式之一批准CSR：

如果已配置了自动批准的相关权限（kubeadm:node-autoapprove-bootstrap这个clusterrolebinding），则kube-controller-manager会自动批准CSR：Controller-manager中的CSRApprovingController会校验kubelet发来的CSR的username和group是否具有创建CSR的权限，此外还要验证signerName是否为kubernetes.io/kube-apiserver-client-kubelet，满足上述条件，Controller-manager就会同意CSR请求。
如果没有配置相关权限，管理员可以使用Kubernetes API或kubectl手动批准CSR。kubectl certificate approve

9、CSR同意后，Controller-manager创建kubelet的证书

10、Controller-manager将证书更新至CSR的status字段中。

11、kubelet从apiserver获取新签发的证书

12、kubelet使用获取的key和证书创建kubeconfig文件

13、kubelet启动完成，正常工作。

14、可选：如果配置了node证书自动续期，kubelet在证书即将到期时，会使用之前的kubeconfig文件自动请求更新证书。根据配置，自动或手动批准和颁发续签的证书。如果要自动证书轮替，需要配置kubeadm:node-autoapprove-certificate-rotation这个clusterrolebinding。