威胁模型

下面我们阐述了 Envoy 威胁模型，该模型涉及到 Envoy 的运维人员、开发人员和 安全研究人员。 我们在 https://github.com/envoyproxy/envoy/security/policy 详细介绍了安全发布流程。

机密性、完整性和可用性

我们非常关心会导致数据机密性或完整性受损的漏洞。 对于 Envoy 运维人员，尤其是在边缘部署中使用 Envoy 的运维人员， 与 DoS 和资源耗尽相关的领域中的可用性，也是一个严重的安全问题。

符合以下条件的泄露，我们将激活安全发布流程：

  • 所有导致数据机密性或完整性丧失的问题都会触发安全发布流程。

  • 可用性问题，如死亡查询(QoD)或资源耗尽，需要满足如下所有的标准才会触发安全发布流程：

    • 被标记为硬化的组件受到影响 (查看 核心和扩展 来获取硬化组件列表).

    • 出问题的流量类型（上游或下游）与组件的硬化标签相匹配。 例如：标记为 “hardened to untrusted downstream” 的组件会受到下游请求的影响。

    • 资源耗尽的问题还需要满足一些额外的标准:

      • 超过了当前配置的超时时间或者配置了过短的不切实际的超时时间，也可能是：

        • 内存耗尽，包括内存不足的情况，每个请求的内存占用比配置的 header 或高水位限制多 100 倍或更多。 例如，10 KiB 客户端请求会导致 Envoy 占用 1 MiB 的内存；

        • CPU 使用严重失衡，Envoy 使用比客户端多 100 倍甚至更多的 CPU。

围绕 CPU 和内存 DoS 的 Envoy 可用性立场仍在不断发展，特别是针对暴力攻击。 我们承认，对于作为云基础设施的一部分或使用僵尸网络的 Envoy 部署来说，暴力攻击（即这些放大系数小于 100 的攻击）很可能发生。 我们将继续在社区中迭代和修复众所周知的资源问题，例如负载管理器和 watermark 改进。对当前 Envoy 部署构成风险的暴力披露问题，我们将启动安全进程。

请注意，从可用性的角度来讲，目前我们并不认为 Envoy 的默认配置是安全的。 运维人员必须显示地:ref:配置 <best_practices_edge> watermarks、负载管理器、断路器和其他一些与 Envoy 资源相关的特性来提供可靠的稳定性。 对于缺乏安全默认设置的任何安全披露，我们将不采取行动。 随着时间的流逝，我们将努力改进默认的安全配置，但是由于向后兼容性和性能问题，这将需要遵循重大变更弃用策略。

数据和控制平面

我们将威胁模型分为数据平面和控制平面，从架构的角度反映了 Envoy 内部对这些概念的划分。 我们在风险评估中最优先考虑的是数据平面上不受信任的下游客户端流量所带来的威胁。这反映了在边缘服务能力中使用 Envoy，也反映了在服务网状部署中使用 Envoy 作为入站目的地。

此外，我们对任何可能被不受信任的上游利用的漏洞的立场也在不断变化。我们认识到，鉴于使用 Envoy 作为出口代理，这些构成了严重的安全考虑。 我们将启动安全发布程序，以应对似乎比目前 Envoy 上游加固现状更高的风险状况的披露。

控制平面管理服务器通常是受信任的。 因此，我们不考虑针对 xDS 传输协议的线级漏洞利用。 但是，通过 xDS 传递给 Envoy 的配置可能来自不受信任的来源，并且可能没有完全清除。 例如，服务运营商在 Envoy 上托管多个租户，租户可以在 RouteConfiguration 中的 header 匹配项上指定正则表达式。 在这种情况下，我们期望从机密性、完整性和可用性的角度来看，Envoy 能够抵御恶意配置带来的风险，如上所述。

我们通常认为在请求处理过程中，用于侧呼的服务是可信的，如外部授权、凭证供应商、速率限制服务。当情况并非如此时，将在文档中的扩展明确说明这一点。

核心和扩展

Envoy 核心中的任何东西都可以用于不受信任和受信任的部署。 因此，应在考虑到这种模式的情况下对其进行加固。与核心代码有关的安全问题通常会触发本文所述的安全发布流程。

强化以下扩展以防止不受信任的下游和上游：

以下扩展不应暴露在数据平面攻击向量中，因此旨在对不受信任的下游和上游进行加固：

以下扩展是为了防范不受信任的下游，但假设上游是受信任的：

以下扩展只有在下游和上游都被信任的情况下才能使用：

以下扩展的安全状态未知：

Envoy 目前具有两个支持可加载代码的动态过滤器扩展：WASM 和 Lua。在这两种情况下，我们都假定动态加载的代码是受信任的。我们期望 Lua 的运行时能够在不信任脚本的前提下对不信任的数据平面流量具有鲁棒性, WASM 仍在开发中，但最终将具有类似的安全特征。