生成 CSR 的服务是否应该在将其发送到 Kubernetes API 服务器之前自行批准它?

Should a service generating a CSR self-approve it before sending it to Kubernetes API Server?

我正在努力引入一项新服务,它将与其他服务一起部署在现有节点中。

该服务需要通过 HTTPS 与 Kubernetes API 服务器通信,因此我必须执行 TLS 引导。我能够生成 CSR,但我不知道如何配置控制器管理器来自动批准生成的 CSR。

我在网上浏览了很多资源,发现几乎所有资源都在关注 kubelet TLS bootstrapping,这不适用于我,因为我正在引入一项新服务(不是需要的新节点)引导 kubelet)。如果我错了请纠正我。

考虑我的设计一段时间后,我认为该服务在生成 CSR 后,也可以在将 CSR 发送到 API 服务器之前自行批准 CSR。这意味着控制器管理器现在只需要签署 CSR:high-level flow chart

从安全角度来看,这样的设计合适吗?控制器管理器仍然根据证书颁发机构 (CA) 对 CSR 进行签名,并且为控制器管理器和 API 服务器配置了相同的 CA。

official documentation 中提供了有关证书签名请求的整篇文章。这是一个让你入门的好地方。


通过创建 Custom controller, Normal user service account, and kubernetes.io/kube-apiserver-client 签名者可以实现您想要实现的目标。

您需要创建一个控制器,定期查询 API-Server 的 CSR,并批准它们。
然而,这样的控制器将无法看到 CSR 内部的内容,因此会打开您的集群以进行恶意 CSR 注入。

A Word of Warning on the Approval Permission:

The ability to approve CSRs decides who trusts whom within your environment. The ability to approve CSRs should not be granted broadly or lightly. The requirements of the challenge noted in the previous section and the repercussions of issuing a specific certificate should be fully understood before granting this permission.