k8s 之 TLS Bootstrapping

参考

TLS bootstrapping
Using RBAC Authorization
Kubelet Server Certificate Bootstrap & Rotation

在一个 Kubernetes 集群中，工作节点上的组件（kubelet 和 kube-proxy）需要与 Kubernetes 控制平面组件通信，尤其是 kube-apiserver。 为了确保通信本身是私密的、不被干扰，并且确保集群的每个组件都在与另一个 可信的组件通信，我们强烈建议使用节点上的客户端 TLS 证书。

启动引导这些组件的正常过程，尤其是需要证书来与 kube-apiserver 安全通信的 工作节点，可能会是一个具有挑战性的过程，因为这一过程通常不受 Kubernetes 控制， 需要不少额外工作。 这也使得初始化或者扩缩一个集群的操作变得具有挑战性。

为了简化这一过程，从 1.4 版本开始，Kubernetes 引入了一个证书请求和签名 API 以便简化此过程。该提案可在 这里看到。

TLS Bootstrapping证书详解

• 此环境中ControllerManager/Scheduler组件是手动颁发的证书。
• TLS Bootstrapping：是为node节点自动的生成 和管理证书的。
• Node节点为什么不去手动的生成证书和管理证书：因为node节点动态性比较强，
• 不像master节点下的ControllerManager/Scheduler这类组件部署之后就不会动。
• 而Keepalived的主机名和node节点的主机名是有绑定的，
• 所以说当手动管理证书的情况下，集群规模很大的时候，管理起来就比较麻烦。
• controller-manager安装的时候为每个k8s的组件都生成了一个controller-manager.kubeconfig文件；
• 这个文件保存了apiserver的信息及去连接apiserver是所需要的证书。

启用 TLS Bootstrapping 机制

当集群开启了 TLS 认证后，node 节点上的 kubelet 和 kube-proxy 组件都要使用 apiserver 签发的有效证书才能与 apiserver 通信，当 node 节点过多时，TLS Bootstrapping 功能让 kubelet 先使用低权限用户连接到 apserver，然后向 apiserver 申请证书，kubelet 的证书是由 apiserver 动态签发，配合 RBAC 授权默写工作流量如下：
首先需要了解两个概念， TLS RBAC 模型
TLS 用来对通讯加密，防止中间人窃听，如果证书不信任就无法与 apiserver 建议连接，更不用提有没有权限向 api 请求指定内容。
RBAC 模型 在 TLS 解决了通讯问题，权限问题有 RBAC 解决 (ABAC 模型也可以)，RBAC 会规定用户或者用户组具有请求那些 aip 的权限，配合 TLS 加密后，实际上 apiserver 读取客户端证书 CN 字段作为用户名，读取 O 字段作为用户组。
可知两点：想要与 apiserver 通讯就必须采用 apiserver CA 颁发的证书，才能建立连接。
通过证书的 CN、O 字段来提供 RBAC 所需的用户与用户组。
TLS Bootstrapping 工作流程 ：

由此产生问题： 既然 TLS bootstrapping 功能让 kubelet 去 appserver 申请证书，用户连接 appserver，那么第一次启动时没有证书如何连接到 appserver。
查看 bootstrap.kubeconfig 和 token.csv 后，发现在 apiserver 配置中指定了 token.csv 文件，这个文件有一个预设的用户配置，这个用户 token 和 apiserver 的 CA 证书写入到 kubelet 所用户 bootstrap.kubeconfig 配置文件，
当节点首次请求时，kubelet 使用 bootstrap.kubeconfig 中 apiserver 的 CA 证书与 appserver 建立 TLS 连接，
还需要使用 bootstrap.kubeconfig 中的 用户 token 来向 apiserver 证明自己的 RBAC 授权身份。如下图：

查看apiserver保存的证书信息

[root@k8s-master01 ~]# cat /usr/lib/systemd/system/kube-controller-manager.service | grep kubeconfig
      --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig \               //在这个文件指定了controller-manager.kubeconfig
[root@k8s-master01 ~]# ls /etc/kubernetes/controller-manager.kubeconfig 
/etc/kubernetes/controller-manager.kubeconfig

这个组件在启动的时候会拿着这个文件达到认证的作用，通讯是加密的。

查看kubelet.kubeconfig

[root@k8s-master01 ~]# ls /etc/kubernetes/kubelet.kubeconfig 
/etc/kubernetes/kubelet.kubeconfig

kubelet也有自己的证书。
kubelet不建议手动去颁发管理证书。所以引入了TLS Bootstrapping；
它会为kubelet自动的去颁发一个kubelet.kubeconfig证书。

TLS BootStrapping证书生成流程

TLS证书生成原理

在配置一个Node节点的时候，Node节点上是没有这个文件的。

• 生成原理：通过bootstrap-kubelet.kubeconfig该文件和ApiServer进行交互然后自动的去申请一个kubelet.kubeconfig 文件
  若是Node节点在启动的时候，没有kubelet.kubeconfig这个文件，
  它会拿这个bootstrap-kubelet.kubeconfig文件也就是BootStrapping认证的kubeconfig
  去申请一个kubelet.kubeconfig，然后在去启动它的进程。

TLS证书生成流程

查看kubernetes证书文件并删除原有的kubelet.kubeconfig配置文件
查看kubernetes证书文件

[root@k8s-node01 ~]# ll /etc/kubernetes/kubelet.kubeconfig 
-rw------- 1 root root 2371 Jun 28 19:19 /etc/kubernetes/kubelet.kubeconfig

查看kubelet的启动配置文件

[root@k8s-node01 ~]# cat /etc/systemd/system/kubelet.service.d/10-kubelet.conf 
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig --kubeconfig=/etc/kubernetes/kubelet.kubeconfig"   
 注:解释说明
    --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig // 指定的kubeconfig文件
    --kubeconfig=/etc/kubernetes/kubelet.kubeconfig"                    // 生成的文件   
可以看到指定了bootstrap-kubelet.kubeconfig，和kubelet.kubeconfig
如果kubelet.kubeconfig文件不存在，kubelet会拿着bootstrap-kubelet.kubeconfig与apiserver进行交互
申请一个新的kubelet.kubeconfig文件然后启动kubelet
···

删除原有的 kubelet.kubeconfig文件

[root@k8s-node01 ~]# rm -f /etc/kubernetes/kubelet.kubeconfig

重启kubelet并生成证书文件

[root@k8s-node01 ~]# systemctl restart kubelet

查看生成的kubeconfig证书文件，生成完之后就会和ApiServer进行交互

[root@k8s-node01 ~]# ll /etc/kubernetes/kubelet.kubeconfig 
-rw------- 1 root root 2371 Jul  2 18:01 /etc/kubernetes/kubelet.kubeconfig
[root@k8s-node01 ~]# date
Sat Jul  2 18:02:02 CST 2022

kubelet启动过程

初始化过程

以下为官方文档内容仅供参考

当工作节点启动时，kubelet 执行以下操作：

1. 寻找自己的 kubeconfig 文件
2. 检索 API 服务器的 URL 和凭据，通常是来自 kubeconfig 文件中的 TLS 密钥和已签名证书
3. 尝试使用这些凭据来与 API 服务器通信

假定 kube-apiserver 成功地认证了 kubelet 的凭据数据，它会将 kubelet 视为 一个合法的节点并开始将 Pods 分派给该节点。

注意，签名的过程依赖于：

• kubeconfig 中包含密钥和本地主机的证书
• 证书被 kube-apiserver 所信任的一个证书机构（CA）所签名

负责部署和管理集群的人有以下责任：

1. 创建 CA 密钥和证书
2. 将 CA 证书发布到 kube-apiserver 运行所在的控制平面节点上
3. 为每个 kubelet 创建密钥和证书；强烈建议为每个 kubelet 使用独一无二的、 CN 取值与众不同的密钥和证书
4. 使用 CA 密钥对 kubelet 证书签名
5. 将 kubelet 密钥和签名的证书发布到 kubelet 运行所在的特定节点上

本文中描述的 TLS 启动引导过程有意简化甚至完全自动化上述过程，尤其是 第三步之后的操作，因为这些步骤是初始化或者扩缩集群时最常见的操作。

启动引导初始化

bootstrapping CSR申请和证书颁发原理与证书接近过期自动续期原理

在启动引导初始化过程中，会发生以下事情：

1. kubelet 启动
2. kubelet 看到自己没有对应的 kubeconfig 文件
3. kubelet 搜索并发现 bootstrap-kubeconfig 文件
4. kubelet 读取该启动引导文件，从中获得 API 服务器的 URL 和用途有限的 一个“令牌（Token）”
5. kubelet 建立与 API 服务器的连接，使用上述令牌执行身份认证
6. kubelet 现在拥有受限制的凭据来创建和取回证书签名请求（CSR）
7. kubelet 为自己创建一个 CSR，并将其 signerName 设置为 kubernetes.io/kube-apiserver-client-kubelet
8. CSR 被以如下两种方式之一批复：
   • 如果配置了，kube-controller-manager 会自动批复该 CSR
   • 如果配置了，一个外部进程，或者是人，使用 Kubernetes API 或者使用 kubectl 来批复该 CSR
9. kubelet 所需要的证书被创建
10. 证书被发放给 kubelet
11. kubelet 取回该证书
12. kubelet 创建一个合适的 kubeconfig，其中包含密钥和已签名的证书
13. kubelet 开始正常操作
14. 可选地，如果配置了，kubelet 在证书接近于过期时自动请求更新证书
15. 更新的证书被批复并发放；取决于配置，这一过程可能是自动的或者手动完成