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

涉及出口流量的攻击以及出口流量控制的要求。

2019 年 5 月 22 日 | 作者：Vadim Eisenberg - IBM

这是我即将发布的关于 Istio 中出口流量安全控制的新系列文章的第一部分。在本期文章中，我将解释为什么您应该将出口流量控制应用于您的集群、您想要防止的涉及出口流量的攻击以及出口流量控制系统为此需要满足的要求。一旦您同意应该控制来自集群的出口流量，就会出现以下问题：安全控制出口流量的系统需要哪些要求？哪个解决方案最能满足这些要求？（剧透：我认为是 Istio）后续文章将介绍 在 Istio 中实现出口流量安全控制 并将其与其他解决方案进行比较。

对于服务网格来说，最重要的安全方面可能是入口流量。您绝对必须防止攻击者通过入口 API 渗透集群。话虽如此，确保离开网格的流量也很重要。一旦您的集群受到攻击，并且您必须为此场景做好准备，您需要尽可能减少损害并防止攻击者使用集群对集群外部的外部服务和遗留系统发起进一步攻击。为了实现这一目标，您需要对出口流量进行安全控制。

合规性要求是实施出口流量安全控制的另一个原因。例如，支付卡行业 (PCI) 数据安全标准 要求必须将入站和出站流量限制为必要的流量。

特别是关于出站流量

让我们从涉及出口流量的攻击开始。

攻击

如果某个 IT 组织尚未遭到攻击，则必须假设它将遭到攻击，并且其基础设施的一部分可能已经受到攻击或将来会受到攻击。一旦攻击者能够渗透到集群中的某个应用程序，他们就可以继续攻击外部服务：遗留系统、外部 Web 服务和数据库。攻击者可能想要窃取应用程序的数据并将其传输到其外部服务器。攻击者的恶意软件可能需要访问攻击者的服务器以下载更新。攻击者可能会使用集群中的 Pod 执行 DDoS 攻击或侵入外部系统。即使您无法知道所有可能的攻击类型，您也希望减少任何攻击的可能性，无论已知还是未知的攻击。

外部攻击者通过应用程序中的漏洞从网格外部访问应用程序的容器，但攻击者也可能是内部人员，例如组织内部的恶意 DevOps 人员。

为了防止上述攻击，必须应用某种形式的出口流量控制。请允许我在下一节中介绍出口流量控制。

解决方案：出口流量的安全控制

出口流量的安全控制意味着监控出口流量并执行所有关于出口流量的安全策略。监控出口流量使您能够对其进行分析（可能是在脱机状态下），并检测攻击，即使您无法实时阻止它们。减少攻击可能性的另一个最佳实践是指定限制访问权限的策略，遵循知情权原则：只有需要外部服务的应用程序才能被允许访问其所需的外部服务。

现在，让我转向我们收集的出口流量控制要求。

出口流量控制的要求

我和 IBM 的同事从多个客户那里收集了出口流量安全控制的要求，并将它们与Kubernetes 网络特别兴趣小组的出口流量控制要求相结合。

Istio 1.1 满足所有收集到的要求

  1. 支持使用TLS 和SNI 或通过 Istio 进行TLS 发起。

  2. 监控每个出口访问的 SNI 和源工作负载。

  3. 定义和执行每个集群的策略，例如：

    • 集群中的所有应用程序都可以访问service1.foo.com（特定主机）

    • 集群中的所有应用程序都可以访问表单*.bar.com（通配符域名）的任何主机

    必须阻止所有未指定的访问。

  4. 定义和执行每个源的策略，Kubernetes 感知

    • 应用程序A可以访问*.foo.com。

    • 应用程序B可以访问*.bar.com。

    必须阻止所有其他访问，特别是应用程序A对service1.bar.com的访问。

  5. 防止篡改。如果应用程序 Pod 受到攻击，请防止受攻击的 Pod 逃脱监控、向监控系统发送虚假信息以及破坏出口策略。

  6. 不错：流量控制对应用程序是透明的。

让我更详细地解释每个要求。第一个要求指出，只支持到外部服务的 TLS 流量。该要求是在观察到所有离开集群的流量都必须加密后提出的。这意味着应用程序执行 TLS 发起或 Istio 必须为它们执行 TLS 发起。请注意，如果应用程序执行 TLS 发起，则 Istio 代理无法查看原始流量，只能查看加密流量，因此代理只能看到 TLS 协议。对于代理来说，原始协议是 HTTP 还是 MongoDB 并不重要，所有 Istio 代理都能看到的是 TLS 流量。

第二个要求指出必须监控 SNI 和流量源。监控是防止攻击的第一步。即使攻击者能够从集群访问外部服务，如果访问受到监控，也可能发现可疑流量并采取纠正措施。

请注意，在应用程序发起 TLS 的情况下，Istio sidecar 代理只能看到 TCP 流量和包含 SNI 的 TLS 握手。源 Pod 的标签可以识别流量的来源，但也可以使用 Pod 的服务帐户或其他一些源标识符。我们将出口控制系统的此属性称为Kubernetes 感知：系统必须理解 Kubernetes 工件（如 Pod 和服务帐户）。如果系统不是 Kubernetes 感知的，它只能监控 IP 地址作为源的标识符。

第三个要求指出，Istio 运营商必须能够为整个集群定义出口流量策略。这些策略说明集群中的任何 Pod 可以访问哪些外部服务。可以通过服务的完全限定域名（例如www.ibm.com）或通配符域名（例如*.ibm.com）来识别外部服务。只能访问指定的外部服务，所有其他出口流量都将被阻止。

此要求源于防止攻击者访问恶意网站（例如下载其恶意软件的更新/说明）的需求。您还需要限制攻击者可以访问和攻击的外部网站数量。您希望仅允许访问集群中的应用程序需要访问的外部服务，并阻止访问所有其他服务，这样可以减少攻击面。虽然外部服务可以拥有自己的安全机制，但您希望执行纵深防御并拥有多个安全层：除了外部系统中的安全层之外，在您的集群中也需要一个安全层。

此要求意味着必须能够通过域名识别外部服务。我们将出口控制系统的此属性称为DNS 感知。如果系统不是 DNS 感知的，则必须通过 IP 地址指定外部服务。使用 IP 地址很不方便，而且通常不可行，因为服务的 IP 地址可能会发生变化。有时甚至不知道服务的所有 IP 地址，例如在CDN 的情况下。

第四个需求规定，必须将出口流量的源添加到策略中，从而有效地扩展了第三个需求。策略可以指定哪个源可以访问哪个外部服务，并且必须像第二个需求中一样识别源，例如，通过源 Pod 的标签或 Pod 的服务帐户来识别。这意味着策略执行也必须是Kubernetes感知的。如果策略执行不是 Kubernetes 感知的，则策略必须通过 Pod 的 IP 来识别流量源，这很不方便，尤其是在 Pod 可以随时创建和销毁，它们的 IP 不是静态的情况下。

第五个需求规定，即使集群遭到入侵，攻击者控制了一些 Pod，他们也必须无法欺骗监控或违反出口控制系统的策略。我们说这样的系统提供了安全的出口流量控制。

第六个需求规定，应在不更改应用程序容器的情况下提供流量控制，特别是无需更改应用程序代码和容器环境。我们称这种出口流量控制为透明的。

在接下来的文章中，我将展示 Istio 可以作为满足所有这些需求的出口流量控制系统的示例，特别是它透明、DNS 感知和 Kubernetes 感知。

总结

我希望您已经相信，控制出口流量对于集群的安全非常重要。在本系列的第 2 部分中，我描述了 Istio 执行安全出口流量控制的方法。在本系列的第 3 部分中，我将其与其他解决方案（例如Kubernetes 网络策略和传统的出口代理/防火墙）进行了比较。

分享此文章