Splunk 的全方位网络安全

市面上有数十种用于保护网络的工具，因此很容易找到教程和演示来展示这些单独的工具如何通过向流量添加身份、策略和可观察性来提高网络安全性。但往往不太清楚的是，这些工具如何协同工作，为您的网络提供全面的生产环境安全。您需要多少工具？您的网络何时足够安全？

本文将探讨 Splunk 用于保护其 Kubernetes 网络基础设施的工具和实践，从 VPC 设计和连接性开始，一直到基于 HTTP 请求的安全。在此过程中，我们将了解为您的云原生堆栈提供全面的网络安全需要什么，这些工具如何协同工作，以及它们中的一些可以改进的地方。Splunk 使用各种工具来保护其网络，包括

• AWS 功能
• Kubernetes
• Istio
• Envoy
• Aviatrix

关于 Splunk 的用例

Splunk 是一家技术公司，它提供一个平台，用于收集、分析和可视化来自各种来源生成的数据。它主要用于通过 Web 样式界面搜索、监控和分析机器生成的大数据。Splunk 云是一项将 Splunk 内部基础设施迁移到云原生架构的举措。如今，Splunk 云由全球各区域的 AWS 和 GCP 中的 35 个以上完全复制的集群组成。

保护第 3/4 层：AWS、Aviatrix 和 Kubernetes

在 Splunk 云中，我们使用一种称为“切饼式 VPC”的模式，其中每个集群都配备了自己的 VPC，具有相同的私有子网（用于 Pod 和节点 IP），一个公共子网（用于进出公用互联网的入口和出口），以及一个内部子网（用于集群之间的流量）。这使来自不同集群的 Pod 和节点完全隔离，同时允许集群外部流量在公共和内部子网中执行特定规则。此外，这种模式还避免了在使用多个集群时可能出现的 RFC 1918 私有 IP 地址耗尽问题。

在每个 VPC 中，网络 ACL 和安全组都设置为限制连接到绝对必要的连接。例如，我们限制了对入口节点的公共连接（将部署 Envoy 入口网关）。除了常见的东/西和北/南流量之外，Splunk 还有一些共享服务需要每个集群访问。Aviatrix 用于提供重叠的 VPC 访问，同时还执行一些高级安全规则（按域进行细分）。

Splunk 堆栈中的下一层安全是 Kubernetes 本身。验证 Webhook 用于防止部署允许集群中不安全流量的 K8S 对象（通常与 NLB 和服务有关）。Splunk 还依赖于 NetworkPolicies 来保护和限制 Pod 到 Pod 的连接。

保护第 7 层：Istio

Splunk 使用 Istio 来根据每个请求的详细信息在应用程序层强制执行策略。Istio 还发出遥测数据（指标、日志、跟踪），这些数据对于验证请求级别的安全很有用。

Istio 注入了 Envoy 边车的关键优势之一是，Istio 可以为整个网格提供传输中加密，而无需对应用程序进行任何修改。应用程序发送明文 HTTP 请求，但 Envoy 边车会拦截流量并实现双向 TLS 加密，以防止拦截或修改。

Istio 管理 Splunk 的入口网关，这些网关接收来自公共和内部 NLB 的流量。网关由平台团队管理，并在 Istio 网关命名空间中运行，允许用户插入网关，但不能修改它们。网关服务还配置了证书，以默认情况下强制执行 TLS，验证 Webhook 确保服务只能连接到其自己主机名的网关。此外，网关在流量能够影响应用程序 Pod 之前在入口处强制执行请求身份验证。

由于 Istio 和相关的 K8S 对象配置起来比较复杂，Splunk 创建了一个抽象层，这是一个控制器，它为服务配置所有内容，包括虚拟服务、目标规则、网关、证书等等。它设置了直接指向正确 NLB 的 DNS。它是一个端到端网络部署的一键式解决方案。对于更复杂的用例，服务团队仍然可以绕过抽象层，直接配置这些设置。

痛点

虽然 Splunk 的架构满足了我们的许多需求，但也有一些值得讨论的痛点。Istio 通过创建与应用程序 Pod 一样多的 Envoy 边车来运行，这是一种低效的资源利用方式。此外，当某个特定应用程序对它的边车有特殊需求时，例如需要额外的 CPU 或内存，很难调整这些设置，而无需为网格中的所有边车调整它们。Istio 边车注入涉及很多“魔法”，使用变异 Webhook 在创建每个 Pod 时添加边车容器，这意味着这些 Pod 不再与其相应的部署匹配。此外，注入只能在 Pod 创建时进行，这意味着每当边车版本或参数更新时，所有 Pod 都必须重新启动才能获得新设置。总的来说，这种“魔法”使在生产环境中运行服务网格变得复杂，并为您的应用程序增加了大量的操作不确定性。

Istio 项目意识到了这些限制，并相信 Istio 的新环境模式将大大改善它们。在这种模式下，身份和加密之类的第 4 层结构将由在节点上运行的守护进程应用，而不是与应用程序在同一个 Pod 中运行。第 7 层功能仍然由 Envoy 处理，但 Envoy 将作为其自身部署的一部分在相邻的 Pod 中运行，而不是依赖于边车注入的“魔法”。应用程序 Pod 不会以任何方式在环境模式中进行修改，这将为服务网格操作增加很大的可预测性。预计环境模式将在 Istio 1.18 中达到 Alpha 质量。

结论

考虑到 Splunk 云中的所有这些网络安全层，退一步看看请求在这些层中传递的过程很有帮助。当客户端发送请求时，他们首先连接到 NLB，该 NLB 将被 VPC ACLs 允许或阻止。然后，NLB 将请求代理到一个入口节点，该节点终止 TLS 并检查第 7 层的请求，选择允许或阻止该请求。然后，Envoy 网关使用 ExtAuthZ 验证请求，以确保它已正确身份验证并满足配额限制，然后才能进入集群。接下来，Envoy 网关将请求代理到上游，Kubernetes 的网络策略再次生效，以确保允许这种代理。工作负载上的上游边车会检查第 7 层请求，如果允许，它将解密请求并将请求以明文形式发送到工作负载。

在满足这家大型企业公司的可扩展性需求的同时，保护 Splunk 的云原生网络堆栈需要在每一层进行仔细的安全规划。

虽然乍一看，在堆栈的每一层应用身份、可观察性和策略原则似乎是多余的，但每一层都能够弥补其他层的不足，因此这些层共同形成了一道严密有效的屏障，阻止了未经授权的访问。

如果您有兴趣更深入地了解 Splunk 的网络安全堆栈，您可以观看我们的云原生安全大会 演示文稿.