应用程序之间 mTLS 的最佳多集群配置

Best multicluster configuration for mTLS between applications

我想用 Istio 多集群配置 2 个 Kubernetes 集群,我正在考虑这两个选项:

  1. 复制的控制平面(https://istio.io/docs/setup/install/multicluster/gateways/
  2. 共享控制平面(单网络)(https://istio.io/docs/setup/install/multicluster/shared-vpn/)

出于可用性原因,我更愿意使用复制的控制平面,但我想到了以下问题:在这种情况下,应用程序之间的 mTLS 是如何工作的?

如果同一集群的 2 个应用程序相互通信,并且启用了 mTLS,我可以创建这样的 AuthorizationPolicy:

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "allow-app-a"
  namespace: app-b
spec:
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/app-a/sa/default"]
    to:
    - operation:
        methods: ["GET"]

app-a 由 mTLS 提供的主体标识。

如果我们正在部署具有复制控制平面的多集群(版本 1),我们将有如下内容:

multicluster with replicated control planes

如何识别不同集群(cluster.global)中的应用程序?所有流量都通过网关,我猜它永远不会从原始调用者那里读取主体,它会从网关读取主体。这样对吗?

有办法解决吗? 我可以获得复制的控制平面但没有网关部署吗?

您应该根据您的要求选择多集群模型,而不是相反。根据 istio documentation:

Shared control plane(单网)模型最简单,主要作为一个mesh跨多个集群使用。


至于复制的控制平面模型,它主要用于可用性和冗余故障转移,其中您在多个区域中拥有集群和网格的副本。这样您就可以在两个集群上实现相同的配置和策略。它也可以像 here.

那样以高级方式使用

Istio documentation 将复制的控制平面总结如下:

Using Istio gateways, a common root CA, and service entries, you can configure a single Istio service mesh across multiple Kubernetes clusters. Once configured this way, traffic can be transparently routed to remote clusters without any application involvement. Although this approach requires a certain amount of manual configuration for remote service access, the service entry creation process could be automated.

关于跨集群通信和mTLS 根据documentation:

Cross cluster communication requires mutual TLS connection between services. To enable mutual TLS communication across clusters, each cluster’s Citadel will be configured with intermediate CA credentials generated by a shared root CA. For illustration purposes, you use a sample root CA certificate available in the Istio installation under the samples/certs directory.


How are applications in different cluster (cluster.global) identified?

通过 host 名称将应用程序引入服务网格注册表。您可以使用 ServiceEntry 对象来配置服务的全局可见性。你可以找到一个例子 here.

multi-mesh deployment feature 之一是:

None of the services in a mesh are exposed by default, the mesh owners must explicitly specify which services are exposed.


All traffic is going through the gateway, my guess is that it will never read the principal from the original caller, it will read the principal from the gateway. Is this right?

这取决于您的 Gateway 配置。您可以使用 Ingress Gateway without TLS Termination 指示网关按原样传递入口流量,而不终止 TLS。这样源地址将被保留。

Can I get replicated control planes but with no gateways deployments?

不,对于具有复制控制平面的多集群模型,每个集群仍有其 Gateways 用于路由。

希望这对您有所帮助。