![Kubernetes:使用由自签名根 CA 证书签名的中间 CA](https://linux22.com/image/776968/Kubernetes%EF%BC%9A%E4%BD%BF%E7%94%A8%E7%94%B1%E8%87%AA%E7%AD%BE%E5%90%8D%E6%A0%B9%20CA%20%E8%AF%81%E4%B9%A6%E7%AD%BE%E5%90%8D%E7%9A%84%E4%B8%AD%E9%97%B4%20CA.png)
是否有人对 Kubernetes 集群使用自己的证书链?
这种设置存在问题,如果您能提供任何解决方法我将非常感激。
假设我们有一个根 CA,其证书是自签名的。此外,我们还有一个中间 CA,其证书由根 CA 签名。我们创建一个认证链(通过将两个 PEM 容器连接到一个文件中)并用它来设置 Kubernetes。几乎所有东西都运行良好:Kubernetes 运行良好,Kubernetes 客户端运行良好,Kubernetes 操作员运行良好……生活很美好。
但有一件事我们必须记住。所有Secret
包含对象安全令牌的对象ServiceAccount
都有 CA 证书的“缩短”版本。“缩短”版本不包含根 CA 证书,只包含中间证书。
正如我所见,对于大多数 TLS 库来说这已经足够了。一个软件与 Kubernetes API 服务器建立 TLS 连接,确保服务器的证书由受信任的 CA 签名(假设从相关机构获得的中级 CA 证书是受Secret
信任的),一切顺利进行。
但有时我们会遇到问题。当我们的某个软件(例如 Kubernetes 操作员或任何其他需要与 Kubernetes API 服务器通信的程序)使用稍微严格一些的 TLS 库时,我们就会遇到麻烦。在这种情况下,我们必须为该工具提供认证链的版本(包含中间 CA 证书和根证书),因为 Kubernetes 提供的“缩短”版本是不够的。如果我们能够为该工具提供完整的证书链,那就没问题了,但有时这是不可能的,所以它会从中获取“缩短”的 CA 证书,而/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
说服它从其他来源获取 CA 证书并不容易。 :-(
我的问题是:有没有办法让 KubernetesSecret
使用完整版本的认证链创建这些对象?如果有,是否会引起其他类型的困难(例如,如果完整链提供的软件出现故障)?或者,也许还有其他解决方法?
提前致谢。