Istio 中的出口流量安全控制，第 2 部分

使用 Istio 出口流量控制来防止涉及出口流量的攻击。

2019 年 7 月 10 日 | 作者：Vadim Eisenberg - IBM

欢迎来到我们关于 Istio 中出口流量安全控制的新系列的第 2 部分。在本系列的第一部分中，我介绍了涉及出口流量的攻击以及我们为出口流量安全控制系统收集的需求。在本期中，我将描述 Istio 安全控制出口流量的方式，并展示 Istio 如何帮助您防止攻击。

Istio 中的出口流量安全控制

要在 Istio 中实现出口流量的安全控制，您必须通过出口网关将 TLS 流量定向到外部服务。或者，您可以通过出口网关定向 HTTP 流量，并让出口网关执行 TLS 来源。

两种方案都有各自的优缺点，您应根据自己的情况在它们之间进行选择。选择主要取决于您的应用程序是否可以发送未加密的 HTTP 请求以及您组织的安全策略是否允许发送未加密的 HTTP 请求。例如，如果您的应用程序使用某些加密流量而无法取消加密的客户端库，则无法使用发送未加密 HTTP 流量的选项。如果您的组织的安全策略不允许在 Pod 内（在 Pod 外部，流量由 Istio 加密）发送未加密的 HTTP 请求，则情况也是如此。

如果应用程序发送 HTTP 请求并且出口网关执行 TLS 来源，您可以监控 HTTP 信息，例如 HTTP 方法、标头和 URL 路径。您还可以根据上述 HTTP 信息定义策略。如果应用程序执行 TLS 来源，您可以监控 SNI 和源 Pod 的 TLS 流量的服务帐户，并根据 SNI 和服务帐户定义策略。

您必须确保来自您集群到外部的流量不能绕过出口网关。Istio 无法为您执行此操作，因此您必须应用一些其他安全机制，例如Kubernetes 网络策略或 L3 防火墙。查看Kubernetes 网络策略配置的示例。根据纵深防御的概念，您为同一目标应用的安全机制越多，效果越好。

您还必须确保 Istio 控制平面和出口网关不会被破坏。虽然您的集群中可能拥有数百或数千个应用程序 Pod，但只有十几個 Istio 控制平面 Pod 和网关。您可以并且应该专注于保护控制平面 Pod 和网关，因为这样做很简单（只需要保护少量 Pod）并且对集群的安全至关重要。如果攻击者破坏了控制平面或出口网关，他们可能会违反任何策略。

您可能拥有多种工具来保护控制平面 Pod，具体取决于您的环境。合理的安全措施是

在与应用程序节点不同的节点上运行控制平面 Pod。
在它们自己的独立命名空间中运行控制平面 Pod。
应用 Kubernetes RBAC 和网络策略来保护控制平面 Pod。
比您监控应用程序 Pod 更密切地监控控制平面 Pod。

将出口流量定向到出口网关并应用其他安全机制后，您可以安全地监控和强制执行流量的安全策略。

下图显示了 Istio 的安全架构，并添加了 L3 防火墙，它是其他安全机制的一部分，应该在 Istio 之外提供。

Istio Security Architecture with Egress Gateway and L3 Firewall — 带有出口网关和 L3 防火墙的 Istio 安全架构

您可以轻松地配置 L3 防火墙，只允许通过 Istio 入口网关传入流量，只允许通过 Istio 出口网关传出流量。网关的 Istio 代理会像网格中的所有其他代理一样强制执行策略并报告遥测数据。

现在，让我们检查一下可能的攻击，让我向您展示 Istio 中的出口流量安全控制如何防止它们。

防止可能的攻击

考虑以下出口流量的安全策略

应用程序A被允许访问*.ibm.com，其中包括所有与*.ibm.com匹配的 URL 的外部服务。
应用程序B被允许访问mongo1.composedb.com。
所有出口流量都将被监控。

假设攻击者具有以下目标

从您的集群访问*.ibm.com。
从您的集群访问*.ibm.com，但未经监控。攻击者希望他们的流量未经监控，以防止您检测到禁止的访问。
从您的集群访问mongo1.composedb.com。

现在假设攻击者设法入侵了应用程序A的某个 Pod，并尝试使用被破坏的 Pod 执行禁止的访问。攻击者可能会尝试他们的运气并以直接的方式访问外部服务。您将按照以下步骤应对直接尝试

最初，没有办法阻止被破坏的应用程序A访问*.ibm.com，因为被破坏的 Pod 与原始 Pod 无法区分。
幸运的是，您可以监控对所有外部服务的访问，检测可疑流量，并阻止攻击者获得对*.ibm.com的未经监控的访问。例如，您可以对出口流量日志应用异常检测工具。
为了阻止攻击者从您的集群访问mongo1.composedb.com，Istio 将正确检测流量的来源（在本例中为应用程序A），并验证根据上述安全策略，它是否被允许访问mongo1.composedb.com。

在无法以直接方式实现其目标后，恶意行为者可能会诉诸高级攻击

绕过容器的 Sidecar 代理，以便能够直接访问任何外部服务，而无需 Sidecar 的策略强制执行和报告。此攻击通过 Kubernetes 网络策略或 L3 防火墙来防止，这些策略或防火墙只允许出口流量从出口网关退出网格。
破坏出口网关，以便能够强制其向监控系统发送虚假信息或禁用安全策略的强制执行。此攻击通过对出口网关 Pod 应用特殊安全措施来防止。
假扮应用程序 B，因为应用程序B被允许访问mongo1.composedb.com。幸运的是，此攻击被 Istio 的强大的身份支持阻止。

据我们所知，所有禁止的访问都将被阻止，或者至少将被监控并可以在以后被阻止。如果您看到其他涉及出口流量的攻击或当前设计中的安全漏洞，我们很乐意听取您的意见.

总结

希望我能说服您 Istio 是防止涉及出口流量的攻击的有效工具。在本系列的下一部分中，我将比较 Istio 中的出口流量安全控制与其他解决方案，例如Kubernetes 网络策略和传统的出口代理/防火墙。