Ambient 模式安全深入探讨
深入研究最近发布的 Istio 无边车数据平面 Ambient 模式的安全隐患。
我们最近发布了 Istio Ambient 模式， 它是一种 Istio 无边车数据平面以及 Ambient 网格模式的参考实现。 正如在公告博客中的所述， 我们对 Ambient 网格的首要关注是简化操作、更广泛的应用程序兼容性、 降低基础设施成本以及提高性能。在设计 Ambient 数据平面时， 我们希望在不牺牲安全性或功能的前提下仔细思考对于操作、 成本和性能的平衡。随着 Ambient 网格的组件在应用程序 Pod 之外运行， 安全边界发生了变化 —— 我们相信这会变得更好。在此博客中， 我们将详细介绍这些更改以及它们与 Sidecar 部署模式的比较。
回顾一下，Istio 的 Ambient 模式引入了一个分层的网格数据平面， 它带有一个负责传输安全和路由的安全覆盖层，可以为需要它们的命名空间选择添加 L7 能力。 需要了解更多信息， 请参阅公告博客和入门博客。 安全覆盖层由一个节点共享组件 ztunnel 构成， 它负责 L4 遥测功能以及以 DaemonSet 模式部署的 mTLS 功能。 网格的 L7 层由路点代理提供，这是按身份/工作负载类型部署的完整 L7 Envoy 代理。 此设计的一些核心定义包括：
- 应用程序和数据平面分离
- 安全覆盖层组件近似于 CNI
- 简化操作更有利于安全
- 避免多租户 L7 代理
- Sidecar 模式仍然是首推部署模式
应用程序和数据平面分离
尽管实现 Ambient Mesh 的主要目标是为了简化服务网格的操作， 但它确实也有助于提高安全性。复杂性升高将滋生漏洞， 而企业级应用程序（及其可传递依赖项、库和框架）极其复杂且更容易出现漏洞。 无论是处理复杂的业务逻辑，还是使用 OSS 库或有缺陷的内部共享库， 用户的应用程序代码总是（内部或外部）攻击者的主要目标。如果应用程序遭到破坏， 其凭据、Secret 和密钥，以及那些安装或存储在内存中的内容都会暴露给攻击者。 再来看 Sidecar 模式，应用程序不得不接纳包括 Sidecar 及其任何相关的身份/密钥材料。 而在 Istio Ambient 模式下，数据平面组件与应用程序不会在同一个 Pod 中运行， 因此应用程序的妥协不会导致机密内容被访问。
当 Envoy 代理被作为漏洞的潜在目标怎么样？Envoy 是一个非常稳固的基础设施， 并受到严格审查，以及在关键环境中大规模运行（例如， 在谷歌用于生产环境中的网络前端）。 但是，由于 Envoy 也是软件，因此它无法避免漏洞。当这些漏洞确实出现时， Envoy 有一个强大的 CVE 流程来识别以及快速修复它们， 并在它们有机会产生广泛影响之前将其推广给相关客户。
回到之前关于“复杂性滋生漏洞”的评论，Envoy 代理最复杂的部分是在其 L7 处理中， 事实上，从历史数据来看，Envoy 的绝大部分漏洞也确实存在于其 L7 处理堆栈中。 但是，如果您只是将 Istio 用于 mTLS 功能又当如何？当您不使用相关功能时， 为什么要冒险部署具有更高 CVE 风险的完整功能 L7 代理？而分离 L4 和 L7 网格功能就可以在这里发挥作用。在 Sidecar 部署模式中，即使您只使用一小部分功能， 您也要以妥协的方式启用整个代理，但在 Ambient 模式下，我们可以通过提供安全覆盖层以及仅根据需要在 L7 中分层限制相关功能的暴露。此外，L7 组件与应用程序完全分离运行，这也避免了提供攻击途径。
将 L4 支持推进到 CNI
Ambient 模式数据平面的 L4 组件是以 DaemonSet 形式，或者基于每个节点的形式来运行。 这意味着它是以共享基础设施的方式在特定节点上与其他 Pod 一同运行的。 由于该组件特别敏感，因此该组件应与节点上的其他共享组件（例如其他 CNI 代理、kube-proxy、kubelet 甚至 Linux 内核）处于同等级别。 来自工作负载的流量在识别到工作负载并选择正确的证书来表示 mTLS 连接中的该工作负载信息后被重定向到 ztunnel。
与此同时 ztunnel 为每个 Pod 提供不同的凭证，并且仅当 Pod 在当前节点上运行时才会颁发该凭证。这确保了当 ztunnel 受损时， 其影响范围控制在只有与组件处于相同节点上的 Pod 凭据可能被盗。 这是与其他包括安全 CNI 实现良好共享节点基础设施的类似方式。 ztunnel 不使用集群范围或每个节点的凭据，如果这些凭据被盗， 可能会立即危及集群中所有应用程序的流量，除非还实施了复杂的辅助授权机制。
如果我们将其与 Sidecar 模式进行比较，我们会注意到 ztunnel 是共享的， 妥协方式可能会导致节点上运行的应用程序身份信息泄露。然而，由于 ztunnel 不做任何 L7 处理，因此被攻击面大大缩减（仅 L4 处理），所以该组件中出现 CVE 的可能性低于 Istio Sidecar。此外，Sidecar 中的 CVE（具有更大的 L7 攻击面）并没有真正包含在被破坏的特定工作负载中。Sidecar 中任何严重的 CVE 都可能在网格中其他工作负载中复现。
简化操作更有利于安全
最终，Istio 仍然是必须被维护基础设施中的关键部分。Istio 被认可代表着应用程序已经实施了零信任网络安全的一些原则， 而至关重要的是应用程序需要按照计划或按照需求推出补丁程序。 平台团队通常有可预测的补丁推出计划或维护周期，这与应用程序的周期大不相同。 当应用程序需要新的能力和功能时，这些通常是项目工作的一部分， 应用程序可能会得到更新。这种应用程序更改、升级、框架和库补丁的方法是相当不可预测的， 这将消耗大量时间，并且不会将自身带入更安全的实践过程中。因此， 将这些安全功能保留在平台的一部分并与应用程序分离可能会带来更好的安全态势。
正如我们在公告博客中指出的那样，操作 Sidecar 可能会更加复杂， 因为它们具有侵入性（注入 Sidecar/更改 Deployment 描述符、重新启动应用程序、 容器之间的竞争条件等）。将工作负载中的 Sidecar 进行升级需要更多的计划和滚动重启， 这可能需要协调才能不导致应用程序崩溃。而使用 Ambient 模式时，对 ztunnel 的升级可以与任何正常的节点修补或升级同时进行，而路点代理是网络的一部分， 可以根据需要完全透明地升级到应用程序。
避免多租户 L7 代理
支持 L7 协议，如 HTTP 1/2/3、gRPC、解析头信息、实现重试以及在数据平面中使用 Wasm 和/或 Lua 进行自定义操作，比支持 L4 复杂得多。 需要更多的代码来实现这些行为（包括 Lua 和 Wasm 之类的用户自定义代码）， 这种复杂性可能会导致潜在的漏洞。因此，CVE 更有可能在 L7 功能的这些区域被发现。
在 Ambient 模式中，我们不会在代理中跨多个身份共享 L7 处理。 每个身份（Kubernetes 中的服务帐户）都有自己专用的 L7 代理（路点代理），这与我们使用 Sidecar 模式非常相似。 尝试将多个身份及其独特的复杂策略以及定制功能放在一起会给共享资源增加很多可变性， 最好的情况下只会导致不平等的成本归因，而最坏的情况下会导致总体代理被迫妥协。
Sidecar 模式仍然是首推部署模式
我们知道有些关注者对 Sidecar 模式感到满意，已知其安全边界，并希望继续使用该模式。 对于 Istio 来说，Sidecar 是网格的首推模式，平台所有者可以选择继续使用它们。 如果平台所有者想要同时支持 Sidecar 和 Ambient 两种模式也是可以的。 具有 Ambient 数据平面的工作负载可以在本地与部署了 Sidecar 的工作负载进行通信。 随着大家更好地了解 Ambient 模式的安全态势，我们相信它将成为 Istio 服务网格数据平面的首选模式，并带有用于特定优化的 Sidecar。
