如何在没有服务发现的情况下配置 Istio 进行网格联合

Question

来自istio 文档的多信任部署模型

\n

\n

我想将多个网格连接在一起。我目前管理 3 个不同的 AKS 集群

\n

\n
• 操作 (aks-ops-euwest-1)
\n
• 分期 (aks-stg-euwest-1)
\n
• 生产 (aks-prod-euwest-1)
\n

\n

我在操作上运行 Hashicorp Vault，我\xe2\x80\x99d 希望能够到达例如。Postgres that\xe2\x80\x99s 使用 istio mTLS 在暂存和生产中运行（用于自动秘密轮换）。

\n

每个集群都在不同的网络中运行 istio（多主）。每个集群都有不同的 ClusterName、MeshID、TrustDomain 和 NetworkID。不过，cacerts秘密是使用通用根 CA配置的

\n

\n

从istio 文档来看，为了实现跨集群通信，eastwestgateway必须部署一个特殊的。tlsMode 是AUTO_PASSTHROUGH。

\n

这些是 eastwestgateway 的环境变量

\n

# sni-dnat adds the clusters required for AUTO_PASSTHROUGH mode\n- name: ISTIO_META_ROUTER_MODE\n  value: "sni-dnat"\n# traffic through this gateway should be routed inside the network\n- name: ISTIO_META_REQUESTED_NETWORK_VIEW\n  value: aks-ops-euwest-1\n

\n

我不想\xe2\x80\x99 不想通过在集群之间共享机密来启用自动服务发现。为什么？因为我想要对网格之间要公开的服务进行细粒度控制。我希望能够指定AuthorizationPolicies指向远程集群的服务帐户（因为不同的信任域）

\n

例如：

\n

# production cluster\nkind: AuthorizationPolicy\nspec:\n  selector:\n    matchLabels:\n      app: postgres\n  rules:\n  - from:\n      source:\n        - principal: spiffe://operations-cluster/ns/vault/sa/vault\n

\n

这是来自istio 文档

\n

\n

在某些高级场景中，可能不需要\n跨集群的负载平衡。例如，在蓝/绿部署中，您可以将不同版本的系统部署到不同的集群。在这种情况下，每个集群都作为独立的网格有效运行。此行为可以通过以下几种方式实现：

\n

\n
• 不要在集群之间交换远程机密。这在集群之间提供了最强的隔离。
\n
• 使用 VirtualService 和 DestinationRule 禁止在两个版本的服务之间进行路由。
\n

\n

\n

istio 文档没有指定如何在不共享机密的情况下启用跨集群通信。共享机密时，istiod 将创建额外的 Envoy 配置，允许 pod 通过 eastwestgateway 透明地进行通信。它没有指定的是如何在不共享机密时手动创建这些配置。

\n

tlsMode 是AUTO_PASSTHROUGH。查看 istio 存储库

\n

    // Similar to the passthrough mode, except servers with this TLS\n    // mode do not require an associated VirtualService to map from\n    // the SNI value to service in the registry. The destination\n    // details such as the service/subset/port are encoded in the\n    // SNI value. The proxy will forward to the upstream (Envoy)\n    // cluster (a group of endpoints) specified by the SNI\n    // value. This server is typically used to provide connectivity\n    // between services in disparate L3 networks that otherwise do\n    // not have direct connectivity between their respective\n    // endpoints. Use of this mode assumes that both the source and\n    // the destination are using Istio mTLS to secure traffic.\n    // In order for this mode to be enabled, the gateway deployment\n    // must be configured with the `ISTIO_META_ROUTER_MODE=sni-dnat`\n    // environment variable.\n

\n

有趣的部分是The destination details such as the service/subset/port are encoded in the SNI value。

\n

看起来，当在集群之间共享秘密时，istio 会添加 envoy 配置，这些配置将有效地将这些服务/子集/端口编码到 Envoy 集群的 SNI 值中。但是，当秘密不共享时，我们如何才能达到相同的结果呢？

\n

我已经查看了这个存储库，但它已经过时并且没有使用eastwestgateway.

\n

我还在 istio 论坛上在这里和这里发布了问题，但很难从那里获得帮助。

\n

Answer 1

在我的公司，我们正在研究服务网格联合的概念，基于以下几点：

• 使用私有 CA 为“客户端”k8s 集群和“提供者”k8s 集群颁发证书。在 istio 安装期间不必使用这些证书。因此，可以使用任何合适的证书来安装 istio，然后从公共私有 CA 生成新证书，专门用于网格联合（安装在入口和出口网关上）。
• 为“provider”k8s 集群设置 mtls 入口，如下所述：https ://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#configure-a-mutual-tls-ingress- gateway，使用公共私有 CA 的证书来设置网关。
• 为“客户端”k8s 集群设置 mtls 出口起源，如下所述：https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/#deploy-a-mutual -tls-server，使用公共私有 CA 的证书来设置网关。
• 使用外部数据库/注册表来存储服务到服务“允许的”连接条目。
• 使用外部 UI 和 API 让“客户端”请求新的服务到服务连接，并让“提供商”批准此类请求。批准后，数据库中的服务间记录标记为“已批准”。（假设“客户端”和“提供商”集群由不同团队拥有和运营。）
• 在“客户端”K8s 集群上使用一些外部自动化从数据库中检索“已批准”记录，并分别设置该集群中的 istio 对象（服务入口、出口网关、虚拟服务、目标规则）。
• 在“提供者”K8s 集群上使用一些外部自动化来从数据库中检索“已批准”记录，并分别设置该集群中的 istio 对象（入口网关、虚拟服务）。
• 使用授权策略明确仅允许特定客户端/证书连接到“provider”k8s 集群的入口，并禁止任何其他证书（特别是由同一私有 CA 颁发的其他证书） - 此处描述https://my. f5.com/manage/s/article/K21084547

当我们向联合添加更多“提供者”和“客户端”时，可能需要调整配置。

结果，我们得到了完全独立的集群和独立的网格，它们可以由不同的团队操作，并且我们让服务（部署到集群）使用来自公共私有 CA 的证书连接到其他集群中的服务，并且我们称之为“网格联盟”。每个集群、每个组件都可以单独操作、独立更新。我们不需要在集群中交叉创建任何秘密，正如 istio 多集群教程中所建议的那样。每个集群中仅公开或消耗有限数量的服务，因此网格联合设置对性能几乎没有影响。集群中的“Client”服务可以使用http连接到“provider”服务，然后请求被istio拦截并发送到各自的httpS入口主机（即“provider”集群），并且mtls认证包含在请求中自动地。无需将证书分发给客户端服务，因为它们已添加到出口网关上。考虑到我们可以保留“宽容”的 istio 身份验证配置，“客户端”服务可以像以前一样继续与集群中的其余服务进行通信，因此将新服务添加到网格联邦应该很容易，就像我们一样不需要更改客户端或提供商端的任何互连配置。