Istio 中出口流量的安全控制，第 3 部分
比较控制出口流量的替代解决方案，包括性能考虑因素。
欢迎阅读我们关于 Istio 中出口流量安全控制系列的第 3 部分。在本系列的第一部分中，我介绍了涉及出口流量的攻击以及我们为出口流量安全控制系统收集的要求。在本系列的第二部分中，我介绍了 Istio 保护出口流量的方式，并展示了如何使用 Istio 防止这些攻击。
在本期中，我将 Istio 中出口流量的安全控制与其他替代解决方案（例如使用 Kubernetes 网络策略和传统出口代理和防火墙）进行了比较。最后，我描述了有关 Istio 中出口流量安全控制的性能考虑因素。
出口流量控制的替代解决方案
首先，让我们回顾一下我们之前收集的出口流量控制要求
- 支持使用SNI 的TLS 或TLS 发起。
- 监控每个出口访问的 SNI 和源工作负载。
- 定义和执行每个集群的策略。
- 定义和执行每个源的策略，Kubernetes 感知。
- 防止篡改.
- 流量控制对应用程序是透明的。
接下来，我将介绍两种出口流量控制的替代解决方案：Kubernetes 网络策略以及出口代理和防火墙。我将展示它们满足的要求，更重要的是，它们无法满足的要求。
Kubernetes 提供了一种用于流量控制的原生解决方案，特别是用于通过网络策略控制出口流量。使用这些网络策略，集群操作员可以配置哪些 Pod 可以访问特定的外部服务。集群操作员可以通过 Pod 标签、命名空间标签或 IP 范围来识别 Pod。为了指定外部服务，集群操作员可以使用 IP 范围，但不能使用像 cnn.com 这样的域名。这是因为Kubernetes 网络策略不了解 DNS。网络策略满足第一个要求，因为它们可以控制任何 TCP 流量。网络策略仅部分满足第三和第四个要求，因为集群操作员可以为每个集群或每个 Pod 指定策略，但操作员无法通过域名识别外部服务。只有当攻击者无法从恶意容器中突破到 Kubernetes 节点并干扰节点内部策略的实施时，网络策略才能满足第五个要求。最后，网络策略确实满足第六个要求：操作员无需更改代码或容器环境。总之，我们可以说 Kubernetes 网络策略提供了透明的、Kubernetes 感知的出口流量控制，但它不了解 DNS。
第二个替代方案早于 Kubernetes 网络策略。使用了解 DNS 的出口代理或防火墙允许您配置应用程序将流量定向到代理并使用某些代理协议，例如SOCKS。由于操作员必须配置应用程序，因此此解决方案不透明。此外，操作员无法使用 Pod 标签或 Pod 服务帐户来配置代理，因为出口代理不知道它们。因此，出口代理不了解 Kubernetes，并且无法满足第四个要求，因为如果 Kubernetes 工件指定了源，则出口代理无法按源执行策略。总之，出口代理可以满足第一、第二、第三和第五个要求，但无法满足第四和第六个要求，因为它们不透明且不了解 Kubernetes。
Istio 出口流量控制的优势
Istio 出口流量控制了解 DNS：您可以根据 URL 或通配符域名（如 *.ibm.com）定义策略。从这个意义上说，它优于不了解 DNS 的 Kubernetes 网络策略。
Istio 出口流量控制对于 TLS 流量是透明的，因为 Istio 是透明的：您无需更改应用程序或配置其容器。对于具有 TLS 发起的 HTTP 流量，您必须将网格中的应用程序配置为使用 HTTP 而不是 HTTPS。
Istio 出口流量控制了解 Kubernetes：出口流量源的身份基于 Kubernetes 服务帐户。Istio 出口流量控制优于不透明且不了解 Kubernetes 的传统了解 DNS 的代理或防火墙。
Istio 出口流量控制是安全的：它基于 Istio 的强大身份，并且当您应用其他安全措施时，Istio 的流量控制能够抵御篡改。
此外，Istio 的出口流量控制提供了以下优势
- 使用相同的语言为入口、出口和集群内流量定义访问策略。您需要学习一种适用于所有类型流量的策略和配置语言。
- Istio 的出口流量控制与 Istio 的策略和可观察性适配器集成。
- 仅需编写一次适配器以使用外部监控或访问控制系统与 Istio 集成，并将其应用于所有类型的流量：入口、出口和集群内。
- 将 Istio 的流量管理功能用于出口流量：负载均衡、被动和主动健康检查、断路器、超时、重试、故障注入等。
我们将具有上述优势的系统称为Istio 感知。
下表总结了 Istio 和替代解决方案提供的出口流量控制功能
| Istio 出口流量控制 | Kubernetes 网络策略 | 传统出口代理或防火墙 | |
|---|---|---|---|
| 了解 DNS | |||
| 了解 Kubernetes | |||
| 透明 | |||
| Istio 感知 |
性能考虑因素
使用 Istio 控制出口流量需要付出一定的代价：增加对外部服务的调用延迟以及集群 Pod 的 CPU 使用率。流量会通过两个代理
- 应用程序的 sidecar 代理
- 出口网关的代理
如果您使用TLS 出口流量到通配符域名，则必须在应用程序和外部服务之间添加其他代理。由于出口网关代理和配置使用通配符的任意域所需的代理之间的流量位于 Pod 的本地网络上，因此该流量不应对延迟产生重大影响。
请参阅不同 Istio 配置集的性能评估，这些配置集设置为控制出口流量。在您决定是否可以承受用例的性能开销之前，我建议您使用自己的应用程序和自己的外部服务仔细测量不同的配置。您应该权衡所需的安全级别与您的性能要求，并比较所有替代解决方案的性能开销。
让我分享一下我对使用 Istio 控制出口流量带来的性能开销的看法：访问外部服务本身可能存在高延迟，并且由于集群内部的两个或三个代理而增加的开销可能与之相比并不显著。毕竟，具有微服务架构的应用程序可以在微服务之间进行数十次调用链。因此，在出口网关中增加一个或两个代理的跳数不应产生重大影响。
此外，我们仍在努力降低 Istio 的性能开销。可能的优化包括
- 扩展 Envoy 以处理通配符域名：这将消除在此用例中应用程序和外部服务之间需要第三个代理的需要。
- 仅使用双向 TLS 进行身份验证，而无需加密 TLS 流量，因为流量已加密。
总结
我希望在阅读完本系列后，您相信控制出口流量对于集群的安全非常重要。希望我也说服了您，Istio 是一个安全控制出口流量的有效工具，并且 Istio 比替代解决方案具有多重优势。就我所知，Istio 是唯一一个允许您执行以下操作的解决方案
- 以安全透明的方式控制出口流量
- 将外部服务指定为域名
- 使用 Kubernetes 工件来指定流量源
在我看来，如果您正在寻找第一个 Istio 用例，则出口流量的安全控制是一个不错的选择。在这种情况下，即使在您开始使用所有其他 Istio 功能之前，Istio 已经为您提供了一些好处：流量管理、安全、策略和可观察性，应用于集群内微服务之间的流量。
因此，如果您还没有机会使用 Istio，请在您的集群上安装 Istio，并查看我们的出口流量控制任务以及其他Istio 功能的任务。我们也希望听到您的意见，请加入我们，访问discuss.istio.io。
