两个kubernetes集群之间的mTLS

Question

我试图在两个 kubernetes 集群中的两个应用程序之间获取 mTLS，而没有 Istio 的方式（使用其入口网关），我想知道以下内容是否有效（对于 Istio，对于 Likerd，对于 Consul...）。

假设我们有一个带有应用程序A. A的k8s集群A和一个带有应用程序B. B的集群B。我希望它们与mTLS通信。

• 集群A为nginx入口控制器提供了letsEncrypt证书，并为其应用程序提供了网格（无论什么）
• 群集B具有来自根CA的自签名证书。
• 群集A和B服务网格具有由我们的根CA签名的不同证书。
• 流量从互联网到群集A入口控制器（HTTPS），从那里到应用程序A.A.
• 流量到达应用程序A.A.后，此应用程序希望与应用程序B.B.通话。
• 应用程序A.A.和B.B.通过入口（使用其入口控制器）公开endpoint
• TLS证书在endpoint结束，是通配符

你认为MTL在这种情况下会起作用吗？

Answer 1

你想要 Consul 的 Mesh Gateways。它们 mTLS 在部署在不同数据中心、群集或运行时环境中的联合 Consul 群集之间的服务到服务连接。

Answer 2

基本上这个来自portshift的博客回答了你的问题。

答案取决于集群的构建方式，因为

Istio提供了一些在多个kubernetes集群中部署服务网格的选项，更多信息请参见此处。

因此，如果您有单网格部署

您可以在完全连接的多集群网络上部署单个服务网格(控制平面),所有工作负载无需Istio网关就可以直接相互连接，无论它们运行在哪个集群上。

但是

如果您有多网格部署

使用多网格部署，您可以获得更大程度的隔离和可用性，但这会增加设置的复杂性。其他独立的网格使用 ServiceEntries、入口网关松散地耦合在一起，并使用公共根 CA 作为安全通信的基础。从网络的角度来看，唯一的要求是入口网关可以相互访问。给定网格中需要访问不同网格中的服务的每个服务都需要远程网格中的 ServiceEntry 配置。

在多网格部署中，随着环境的增长和多样化，安全性可能会变得复杂。在认证和授权集群之间的服务时存在安全挑战。本地混合器（服务策略和遥测）需要使用相邻集群中服务的属性进行更新。否则，当这些服务到达其群集时，它将无法授权这些服务。为了实现这一点，每个混合器需要知道相邻集群中的工作负载标识及其属性。每个Citadel需要使用相邻集群的证书进行更新，以允许集群之间的mTLS连接。

可以通过以下方式跨多网格控制平面合并粒度工作负载标识（mTLS 证书）和服务属性：

< li>Kubernetes Ingress:将HTTP和HTTPS路由从群集外部公开给群集中的服务。流量路由由入口资源上定义的规则控制。入口可以终止SSL / TLS，并提供基于名称的虚拟主机。然而，它需要一个入口控制器来满足入口规则 < li >服务网格网关:Istio服务网格提供不同的配置模型，即Istio网关。网关允许将Istio功能(如监控和路由规则)应用于进入集群的流量。入口网关描述了在网格边缘运行的负载平衡器，其接收传入的HTTP/TCP连接。它配置暴露的端口、协议等。入口流量的流量路由改为使用Istio路由规则进行配置，与内部服务请求的方式完全相同。

你认为MTL在这种情况下会起作用吗？

基于上述信息

>

如果您有单个网格部署

应该可以没有任何问题。

如果您有多网格部署

它应该可以工作，但由于您不想使用istio网关，因此唯一的选择是kubernetes入口。

我希望它能回答你的问题。如果您还有其他问题，请告诉我。