威胁模型

下面我们将阐述 Envoy 威胁模型，这与 Envoy 操作人员、开发人员和安全研究人员相关。 我们详细说明了我们的安全发布流程，请访问 https://github.com/envoyproxy/envoy/security/policy。

机密性、完整性和可用性

我们认为导致数据机密性或完整性受损的漏洞是我们最优先考虑的问题。 可用性，特别是在与 DoS 和资源耗尽相关的领域，也是 Envoy 操作员的严重安全问题，尤其是那些在边缘部署中使用 Envoy 的操作员。

我们将针对满足以下标准的披露启动安全发布流程

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

  • 可用性问题，如 Query-of-Death (QoD) 或资源耗尽，需要满足以下所有标准才能触发安全发布流程

    • 标记为硬化的组件受到影响（有关硬化组件列表，请参阅 核心和扩展）。

    • 出现问题的流量类型（上游或下游）与组件的硬化标签匹配。 例如，标记为“针对不可信下游硬化”的组件受下游请求影响。

    • 资源耗尽问题需要满足以下额外标准

      • 不受现有超时保护，或者应用较短的超时值不切实际，并且

        • 内存耗尽，包括内存不足情况，其中每个请求的内存使用量比配置的报头或高水位线限制高 100 倍或更多。 例如，10 KiB 客户端请求导致 Envoy 消耗 1 MiB 字节的内存；

        • 高度不对称的 CPU 利用率，其中 Envoy 的 CPU 使用率是客户端的 100 倍或更多。

Envoy 关于 CPU 和内存 DoS 的可用性立场仍在不断发展，特别是对于暴力攻击。 我们承认暴力攻击（即放大系数小于 100 的攻击）可能是 Envoy 部署的一部分，作为云基础设施或使用僵尸网络。 我们将继续在公开场合迭代和修复众所周知的资源问题，例如，改进过载管理器和水位线。 我们将针对似乎对现有 Envoy 部署构成风险的暴力攻击披露启动安全流程。

请注意，我们目前不认为 Envoy 的默认设置从可用性角度来看是安全的。 操作人员需要明确 配置 水位线、过载管理器、断路器以及 Envoy 中其他与资源相关的功能，以提供可靠的可用性故事。 我们不会对任何与缺乏安全默认设置相关的安全披露采取行动。 随着时间的推移，我们将努力实现更安全的默认配置，但由于向后兼容性和性能问题，这将需要遵循重大变更弃用策略。

数据平面和控制平面

我们将我们的威胁模型划分为数据平面和控制平面，反映了 Envoy 在架构角度上对这些概念的内部划分。 Envoy 的核心组件被认为是针对不可信的下游和上游对等节点硬化的。 因此，我们在风险评估中优先考虑的是不可信下游客户端或不可信上游服务器流量对数据平面的威胁。 这反映了 Envoy 在边缘服务中的使用，以及 Envoy 作为服务网格部署中具有不可信服务的网络组件的使用。

控制平面管理服务器通常是可信的。 因此，我们不认为针对 xDS 传输协议的线级漏洞是问题。 但是，通过 xDS 传递给 Envoy 的配置可能源自不可信来源，并且可能未完全消毒。 这种情况的例子可能是服务运营商在一个 Envoy 上托管多个租户，其中租户可以在 RouteConfiguration 中指定报头匹配的正则表达式。 在这种情况下，我们预计 Envoy 能够抵御来自不可信配置带来的风险，从机密性、完整性和可用性角度来看，如上所述。

对于需要控制平面和数据平面协调的问题，例如导致 Query of Death 的配置选项，风险由 Envoy 安全团队评估。 如果配置选项存在很长时间，将其关闭会带来风险（例如，关闭过载管理器），而将其开启也会带来风险，安全团队通常会选择在禁运下修复问题。 如果一个功能是新的，并且配置更改总是会导致数据平面崩溃，那么它可能被归类为可信控制平面应禁止的内容，并在明处修复。 对于更微妙的问题，例如，长期存在的配置，其中只有一个变体有问题，安全团队将尝试评估是否存在对任何用户（包括大规模多租户运营商）构成风险的攻击，以确定它是否应该在明处修复。

我们通常假设用于在请求处理期间进行旁路调用的服务（例如，外部授权、凭证提供者、速率限制服务）是可信的。 当情况并非如此时，扩展将在其文档中明确说明这一点。

核心和扩展

Envoy 核心中的任何内容都可以在不可信和可信部署中使用，但明确标记为 alpha 的功能除外；alpha 功能仅在可信部署中受支持，并且不符合下面威胁模型中的处理方式。 因此，稳定的核心应该考虑到这个模型进行硬化。 与核心代码相关的安全问题通常会触发本文件中描述的安全发布流程。

注意

contrib 扩展在下面有说明，并且不受威胁模型或 Envoy 安全团队的正式涵盖。 下面的所有指示都是尽力而为。

以下扩展旨在针对不可信的下游和上游进行硬化

扩展安全：robust_to_untrusted_downstream_and_upstream

以下扩展不应暴露给数据平面攻击向量，因此旨在针对不可信的下游和上游进行硬化

扩展安全：data_plane_agnostic

以下扩展旨在针对不受信任的下游进行加固，但假定上游是可信的

扩展安全性：robust_to_untrusted_downstream

以下扩展应该仅在下游和上游都可信时使用

扩展安全性：requires_trusted_downstream_and_upstream

以下扩展的安全状况未知

扩展安全：unknown

Envoy 目前有两个支持可加载代码的动态过滤器扩展；WASM 和 Lua。在这两种情况下，我们都假设动态加载的代码是可信的。我们期望 Lua 的运行时能够在信任脚本的情况下，抵御来自不可信数据平面流量的攻击。WASM 仍在开发中，但最终将具有类似的安全立场。