行至水穷处 坐看“云”起时

Cloud Native ADN -> CNadn.Net

kubernetes node TLS bootstrapping原理及配置

环境

k8s版本是1.10.6,当前已经使用手工配置的kubeconfig通过证书方式实现kubelet与API的通信,配置如下:

在测试环境中,master节点本身也是一个node节点,通过修改相关配置实现master上这个node节点的kubelet实现自动的TLS bootstrapping.

Node TLS bootstrapping原理

(首先注意这是Node的TLS的bootstrapping,还不是node token bootstrapping)

ndoe是靠节点上的kubelet与API通信实现node向集群中的注册的。因此kubelet需要和API通信,而API又需要认证和授权,纯手工的做法是用集群的CA签发一个证书给kubelet,通过将此证书与key配置在kubeconfig文件里,最后通过设置kubelet启动参数传入该文件实现实现认证和授权。这个证书的特点是:
CN= system:node:k8s-master (node后的名字每个node都不一样)
O=system:nodes
kubeconfig中的user则设置为与CN一致的名字.

这是因为API设置了基于node的授权 --authorization-mode=Node,RBAC

但是这样给每台机器手工这么设置太麻烦了,而且证书如果有效期短,到期前还得手工再处理一遍。所以就有了node boostrapping。那么什么node bootstrapping呢,其原理就是:
-给kubelnet启动时候预先加载一个bootstrap-kubeconfig配置,这个配置总体上类似于上面手工设置的kubeconfig,但是不同的是这个kubeconfig没有配置kubelet客户端证书,而是配置了一个token。

(上述示例输出为实际测试最终的配置)

-API上则提前配置了基于token的认证--token-auth-file=/var/lib/kubernetes/token.csv , 这样kubelet向API出示其token,API根据token.csv里的文件知道了对应的用户名以及该用户属于的组。API server并不需要打开  --enable-bootstrap-token-auth 功能。

-该token对应的用户(token.csv里设置的,这里是kubelet-bootstrap)是绑定到特定的clusterrole的 以便获得权限,如下:

system:node-bootstrapper 实现证书的申请
system:certificate.k8s.io.certificatesigningrequests:nodeclient 实现自动批准证书申请system:certificate.k8s.io.certificatesigningrequests:selfnodeclient 实现自动批准node到期前renew的证书的申请

-kube contoller是执行具体证书的签发人,因此在kube controller的启动参数里需要包含以下配置

这里的signing证书必须是集群的CA所信任的,也就是说它可以是集群CA下的中间CA,这里我们直接配置集群本身的CA

具体操作步骤

  1. 产生一个token.csv 文件

    将上述命令产生的token值,编辑写入一个token.csv文件,并将文件放置在某个目录,一般和API所用的证书目录一致

    注意上述内容的username是kubelet-bootstrap,组是system:kubelet-bootstrap组
  2. 修改API启动配置

     
  3. 修改kube controller配置

     
  4. 执行角色绑定

     
  5. 产生bootstrap-kubeconfig配置文件
  6. 修改kubelet启动配置参数(见上文),需要注意的是--feature-gates=RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true配置,这是一个非正式功能,是用于对证书在到期前进行自动roate的,roate的效果如下,获取新证书(带日期标记,并被软连接)

     

效果验证

 

附录-Kubelet的Webhook授权:

配置kubelet用来授权外部请求的资源权限role

绑定kubernetes这个用户使用上述权限,这个kubernetes用户名是API向kubelnet发起通信时候出示的客户端证书里的CN名字

实际上上述权限的验证授权过程是

-API server向kubelet发起HTTPS请求,SSL通信里API出示了一张证书(证书的CN是kubenetes)

-kubelet通过自己配置的client-ca来验证上述证书,验证通过

-因为kubelet配置webhook的授权模式,所以kubelet向API发起一个查询,这个查询是查询API的SubjectAccessReview 类型API,

–API返回相关授权结果(上述角色的绑定,给与了kubernetes用户权限node资源的权限),授权通过,通信完成。

原创文章,转载请注明来源

参考:
https://v1-10.docs.kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#token-authentication-file

https://v1-10.docs.kubernetes.io/docs/reference/command-line-tools-reference/kubelet/

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注