Envoy 威胁模型全解析：系统上下文、信任边界与安全缓解路线图
【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy
Envoy 是 CNCF 毕业的 L3/L4/L7 代理，以 C++ 编写（Rust 组件逐步增加），既可作为终止不可信互联网流量的edge/front proxy，也可作为微服务网格中每个工作负载旁边的service-mesh sidecar（如 Istio、Cilium、AWS App Mesh、Consul Connect 等场景）。本文基于仓库.agents/threat_model/THREAT_MODEL.md整理其完整威胁模型，涵盖系统上下文、资产清单、入口点与信任边界、威胁清单、优先级降级项与推荐缓解措施，并辅以上游官方文档 threat_model.rst 与仓库源码佐证。读完本文，你将理解 Envoy 的安全姿态（security posture）如何划分、攻击面集中在哪些解析路径、历史上哪些 CVE 印证了这些威胁类别，以及团队应优先落实哪些加固动作。
一、系统上下文：Envoy 的部署角色与安全姿态
1.1 部署角色与协议覆盖
Envoy 支持 HTTP/1.1、HTTP/2、HTTP/3-QUIC、gRPC，以及MCP（Model Context Protocol）、A2A（Agent-to-Agent）等 AI 智能体协议，并通过 filter-chain 扩展模型支持一长串 L7 协议（Redis、Thrift、DNS 等）。其中 MCP 系列过滤器（mcp、mcp_router、mcp_json_rest_bridge、mcp_multicluster）使 Envoy 成为 AI 智能体协议网关：聚合多个 MCP 后端的工具列表，并路由tools/call请求。
这些 MCP 过滤器的实现位于 source/extensions/filters/http/mcp/（含mcp_filter.cc、mcp_json_parser.cc，后者约 935 行）与 source/extensions/filters/http/mcp_router/（mcp_router.cc约 2235 行），多集群能力则实现为集群扩展 source/extensions/clusters/mcp_multicluster/。A2A 过滤器在 source/extensions/filters/http/a2a/（a2a_json_parser.cc约 205 行）。
配置交付方式有两种：静态方式通过 bootstrap YAML；动态方式通过 gRPC/REST 的xDSAPI。此外，mobile/子树将 Envoy 作为 iOS/Android 客户端侧网络库交付（Envoy Mobile）。
1.2 模型覆盖范围
本威胁模型覆盖上游 envoyproxy/envoy 项目按原样交付（as shipped）的部分：核心、Envoy Mobile、CI/发布流水线，以及处于 alpha 阶段的 MCP 与 A2A 扩展。以下内容明确不在范围内（详见 §5）：
contrib/目录下的扩展；- 其他 alpha 状态扩展；
- Windows 专属代码路径。
1.3 与上游官方威胁模型的关系
本项目发布了自己的官方威胁模型文档 threat_model.rst。本文档继承了它，但有一处经负责人指示的分歧（owner-directed divergence）：
ext_authz 与 ext_proc 边调用（side-call）响应在本模型中按"不可信"处理；上游当前声明边调用可信。
其他边调用（限流 rate-limit、访问日志服务 ALS、tracing、凭据供应商 credential suppliers）仍按可信处理。其余上游假设均被采纳：
- 核心场景下，下游与上游对端均不可信（untrusted）；
- xDS 传输层可信；
- Lua/Wasm/动态模块代码可信；
- 管理接口（admin interface）仅限操作者使用；
- DoS 仅在硬化组件上达到 ≥100× 放大或 query-of-death 时才触发安全流程。
1.4 代码规模与历史安全态势
代码库约有3000 个 C++ 源文件，外加约113 个 vendored 依赖（BoringSSL、nghttp2、quiche、c-ares、V8、LuaJIT、wasmtime、RE2、abseil 等）。项目通过 OSS-Fuzz 持续模糊测试，自 2019 年以来发布了80+ 个第一方 CVE/GHSA，主要集中在三类：
- HTTP/2 帧处理导致的 DoS；
- HTTP filter-chain 生命周期中的 use-after-free；
- authn/authz 过滤器的认证/授权绕过。
上游官方模型对安全发布流程有明确门槛：任何导致机密性或完整性损失的问题都触发安全发布流程；可用性问题（如 Query-of-Death 或资源耗尽）需同时满足"影响硬化组件"、"流量类型与组件硬化标签匹配"、以及"内存超配 100× 以上或 CPU 不对称使用 100× 以上"等条件（详见 threat_model.rst 的 "Confidentiality, integrity and availability" 小节）。上游同时明确指出：默认配置下 Envoy 并不具备可用性层面的安全默认值，操作者必须显式配置水位线（watermarks）、过载管理器（overload manager）、熔断器（circuit breakers）等。
二、资产清单（Assets）：哪些东西值得保护
威胁模型以"资产-敏感性"矩阵界定保护对象，共 14 类资产：
| 资产 | 描述 | 敏感性 |
|---|---|---|
| 进程与主机完整性 | 原生 C++ 解析不可信线上字节；内存破坏可导致 RCE，且进程可触达整个网格/边缘 | critical |
| TLS 私钥与会话票据 | SDS/secret manager 持有的服务端/客户端证书私钥与会话票据密钥；泄露 = 被动解密 + 边缘仿冒 | critical |
| 被代理的请求/响应数据 | TLS 终止后每个请求的解密 body、头、cookie、bearer token | critical |
| 服务可用性 | Envoy 是边缘的"前门"与网格的唯一数据路径跳点；解析器崩溃或 OOM 即全站故障 | critical |
| 移动应用进程与设备数据 | Envoy Mobile 运行于 iOS/Android 应用内；沦陷 = 应用权限级代码执行与设备数据访问 | critical |
| 内部上游服务 | 路由表 + 集群管理器赋予 Envoy 对每个后端、metadata server、控制平面的认证触达（SSRF 跳板） | high |
| xDS 配置完整性 | 经 xDS 下发的路由、监听器、集群、RBAC、过滤器字节码；完整性受损 = 任意流量重定向 | high |
| mTLS 工作负载身份 | SPIFFE SVID 校验结果；下游 RBAC 与上游信任均依赖它 | high |
| AuthN/AuthZ 裁决 | jwt_authn 声明、ext_authz allow/deny、RBAC 决策以可信x-envoy-*/ dynamic metadata 传播 | high |
| 注入的上游凭据 | OAuth2 client_secret 与 HMAC 密钥、AWS SigV4 密钥、credential-injector 附加到出站请求的机密 | high |
| 智能体工具调用与能力完整性 | MCP/A2A 的tools/call载荷、能力协商、聚合后的工具列表（下游智能体会据此行动）；被篡改 = 任意工具执行 | high |
| 发布产物完整性 | docker.io/envoyproxy/*镜像、签名 deb/rpm/tarball、Maven Central / PyPI 的 envoy-mobile 包 | high |
| CI/发布机密 | GPG 维护者签名密钥、DockerHub 凭据、GCP SA 密钥、Sonatype 凭据、多个具多仓库写权限的 GitHub App 私钥 | high |
| 访问日志与遥测 | 请求行、头、JWT subject、客户端 IP 落入 file/gRPC/OTel 汇；含 PII 且是完整性目标（日志注入） | medium |
| 内部信任头 | x-envoy-*、XFF、x-request-id被上游视为权威；未剥离 = 信任边界绕过 | medium |
值得强调的是"智能体工具调用与能力完整性"这一新资产类别：它直接对应 MCP/A2A 网关场景，篡改tools/call载荷或聚合工具列表可导致任意工具执行——这正是本文档将 MCP/A2A 过滤器列入威胁清单（T29）的原因。
三、入口点与信任边界（Entry Points & Trust Boundaries）
威胁模型将每个入口点映射到"信任边界 → 可达资产"。以下为全部入口点，按数据平面、控制平面与供应链分组：
3.1 数据平面：下游（客户端）侧
| 入口点 | 描述 | 信任边界 | 可达资产 |
|---|---|---|---|
| Downstream TCP listener | socket accept → listener-filter 链 → network-filteronData；不可信字节的首次接触，见 active_tcp_listener.cc | 不可信 Internet 客户端 → worker 线程 | 进程与主机完整性、服务可用性、被代理数据 |
| Downstream UDP/QUIC ingest | UDPrecvmmsg→ quiche dispatcher；握手前、可伪造源地址，见 active_quic_listener.cc（约 509 行） | 可伪造 Internet UDP → 进程内存 | 进程与主机完整性、服务可用性 |
| HTTP/1 codec | Balsa / http-parser 分词 request-line、头、chunked TE，见 codec_impl.cc（约 1699 行） | 不可信下游字节 → HCM | 进程与主机完整性、被代理数据、AuthN/AuthZ 裁决、内部信任头 |
| HTTP/2 codec | nghttp2/oghttp2 HPACK 解码、流复用、flood 限制、METADATA，见 codec_impl.cc 与 protocol_constraints.cc（约 139 行） | 不可信下游字节 → HCM | 进程与主机完整性、服务可用性、被代理数据 |
| HTTP/3/QUIC codec | quiche QPACK + H3 帧解析、CONNECT-UDP datagrams，见 envoy_quic_server_stream.cc | 不可信下游字节 → HCM | 进程与主机完整性、服务可用性 |
| Listener filters（TLS-inspector / PROXY-protocol） | 手工解析器在 filter-chain 前窥探原始字节提取 SNI/ALPN 或 PROXY v1/v2 TLVs，见 source/extensions/filters/listener/tls_inspector/ 与 source/extensions/filters/listener/proxy_protocol/ | 不可信下游字节 → filter-chain 选择 | 进程与主机完整性、内部信任头、AuthN/AuthZ 裁决 |
| TLS 握手与证书校验 | BoringSSL 握手；客户端证书链校验、SAN/SPKI 匹配、OCSP ASN.1 解析，见 source/common/tls/cert_validator/ | 不可信对端 X.509 → 信任决策 | mTLS 工作负载身份、TLS 私钥与会话票据、进程与主机完整性 |
| Header 与路径归一化 | Header 存储/校验、:path规范化、%2F/斜杠合并，见 path_utility.cc（约 177 行）与 header_utility.cc | 攻击者控制的头 → 安全决策 | AuthN/AuthZ 裁决、内部上游服务、内部信任头 |
| 路由匹配与正则 | VirtualHost/route 求值；租户提供的 RE2 模式作用于攻击者输入，见 config_impl.cc 与 regex.cc | 不可信头 × 半可信配置 → 路由/认证 | 内部上游服务、AuthN/AuthZ 裁决、服务可用性 |
| 非 HTTP L7 codec（核心） | 手写线上解码器：Redis、Thrift、Dubbo、Mongo、ZooKeeper，见source/extensions/filters/network/*/decoder*.cc | 不可信下游字节 → 代理逻辑 | 进程与主机完整性、服务可用性 |
| DNS UDP filter（服务端） | Envoy 作为 DNS 服务器解析任意查询，见 dns_parser.cc | 可伪造 UDP → DNS 解析器 | 进程与主机完整性、服务可用性 |
| MCP / A2A agent-protocol filters | JSON-RPC 请求体解析 + 多后端响应聚合、会话路由，见 source/extensions/filters/http/mcp/、source/extensions/filters/http/mcp_router/、source/extensions/filters/http/a2a/（mcp_json_parser.cc约 23K 行规模、mcp_router.cc约 60K 行规模） | 不可信下游 agent ↔ 不可信上游 MCP/A2A server | 进程与主机完整性、智能体工具调用与能力完整性、内部上游服务、服务可用性 |
| 上游响应路径 | Envoy 作为客户端解析不可信上游 HTTP/1/2/3 响应，见 upstream_request.cc 与 codec_client.cc | 恶意/被攻陷上游 → 进程内存与下游 | 进程与主机完整性、被代理数据、服务可用性 |
| ext_proc / ext_authz 响应 | 边调用 gRPC 返回的 header/body 变更或 allow/deny，Envoy 原样应用，见 mutation_utils.cc 与 source/extensions/filters/common/ext_authz/ | 不可信边调用服务 → 请求变更与 filter-chain 状态（本模型的关键分歧点） | AuthN/AuthZ 裁决、被代理数据、内部信任头、进程与主机完整性 |
| 解压与转码 | gzip/brotli/zstd 解压攻击者 body；gRPC↔JSON 转码，见 source/extensions/compression/*/decompressor/ 与 source/extensions/filters/http/grpc_json_transcoder/ | 不可信 body 字节 → 堆 | 服务可用性、进程与主机完整性 |
| JWT / OAuth2 authn filters | 解析攻击者提供的 JWT（b64/JSON/sig）、OAuth2 重定向/state/cookie、抓取 JWKS，见 source/extensions/filters/http/jwt_authn/ 与 source/extensions/filters/http/oauth2/ | 不可信凭据字节 → 认证决策 | AuthN/AuthZ 裁决、注入的上游凭据、内部上游服务 |
| Access-log formatter | %REQ()%/%RESP()%/%CEL()%将攻击者头插值进日志汇，见 substitution_formatter.cc | 不可信头 → 日志汇 / SIEM | 访问日志与遥测 |
| DNS resolver（客户端） | c-ares / getaddrinfo / Apple / hickory 解析上游 resolver 的响应，见 dns_impl.cc | 不可信 DNS 响应者 → 集群端点 | 进程与主机完整性、内部上游服务 |
| Envoy Mobile 上游摄取 | Envoy Mobile（iOS/Android 客户端库）解析任意服务器的响应；信任模型反转——服务器是攻击者，见 mobile/library/common/ | 恶意源服务器 → 移动应用进程 | 移动应用进程与设备数据、被代理数据 |
3.2 控制平面与供应链
| 入口点 | 描述 | 信任边界 | 可达资产 |
|---|---|---|---|
| xDS 控制平面摄取 | gRPC/REST/filesystem 的DiscoveryResponse→ proto unpack → 实时重配置，见 grpc_mux_impl.cc | 管理服务器（可信传输、半可信载荷）→ 数据平面配置 | xDS 配置完整性、服务可用性、进程与主机完整性 |
| Bazel 依赖获取 | 构建时抓取约 113 个http_archive依赖，SHA256 固定，见 bazel/repository_locations.bzl | 上游维护者 / 镜像 → 编译产物 | 发布产物完整性、进程与主机完整性 |
| GitHub Actions CI 流水线 | pull_request_target→workflow_run链执行 PR 代码；_load.yml中计算的trusted标志门控机密，见 .github/workflows/_run.yml | 外部贡献者 → 持有 org 机密的 CI runner | CI/发布机密、发布产物完整性 |
| 发布产物发布 | Docker push（无 cosign、--provenance=false）、GPG 签名 tarball、Sonatype/PyPI 上传；PyPI action 分支固定，见 distribution/docker/build.sh 与 .github/workflows/mobile-release.yml | CI runner → 公共 registry | 发布产物完整性 |
信任边界要点：数据平面所有入口的边界形态都是"不可信字节 → worker 线程内存"；控制平面 xDS 因上游模型声明"传输可信"而边界较宽（payload 半可信）；而MCP/A2A 过滤器是唯一两端（下游 agent 与上游 MCP/A2A server）都不可信的 HTTP 过滤器，加上 ext_proc/ext_authz 在本模型中被提升为不可信，共同构成需要重点防守的新攻击面。
四、威胁清单（Threats）：按严重级别与可能性
威胁清单以"威胁 ID → 攻击者 → 攻击面 → 受影响资产 → 影响 → 可能性 → 状态 → 控制 → 证据"九元组组织。以下按影响与可能性重新编排，并保留原文全部信息。
4.1 Critical 级威胁
| ID | 威胁 | 攻击者 | 攻击面 | 影响 | 可能性 | 状态 | 控制 | 证据（CVE/GHSA） |
|---|---|---|---|---|---|---|---|---|
| T1 | 流重置/异步回调排序竞争导致 HTTP filter 链 use-after-free 的内存破坏 RCE | remote_unauth | HTTP/1、HTTP/2、HTTP/3 codec、上游响应路径 | 进程与主机完整性 | almost_certain | partially_mitigated | OSS-Fuzz、ASAN CI、deferred-deletion 惯用法 | CVE-2026-26311、CVE-2026-26330、CVE-2024-45810、CVE-2023-35943、CVE-2023-35942、CVE-2022-29227、7be853f757 |
| T2 | auth-filter 逻辑或 header 处理缺陷导致认证/授权绕过 | remote_unauth | JWT/OAuth2 authn filters、Header 与路径归一化、ext_proc/ext_authz 响应、listener filters | AuthN/AuthZ 裁决、内部上游服务 | almost_certain | partially_mitigated | HCM 中 header 清洗、RBAC filter | CVE-2022-29226、CVE-2023-35941、CVE-2026-26308、CVE-2020-25017、CVE-2024-45806、CVE-2025-55162、CVE-2024-23322 |
| T3 | 手写非 HTTP L7 协议解析器导致的内存破坏 RCE | remote_unauth | 非 HTTP L7 codec、DNS UDP filter、listener filters | 进程与主机完整性 | likely | partially_mitigated | 各扩展security_posture标签；OSS-Fuzz 覆盖子集 | CVE-2024-23322~23325、CVE-2026-26310、CVE-2019-18801 |
| T4 | 构造的 HTTP/3/QUIC 流状态迁移导致内存破坏或崩溃 | remote_unauth | UDP/QUIC 摄取、H3 codec | 进程与主机完整性、服务可用性 | likely | partially_mitigated | quiche 由 Google 维护并 fuzz；QUIC 在许多部署中位于 feature flag 后 | CVE-2024-32974、CVE-2024-32976、CVE-2024-34362 |
| T29 | 经 MCP/A2A JSON-RPC 解析与 router 响应构造导致的智能体工具调用篡改、会话混淆或内存破坏 | remote_unauth | MCP/A2A agent-protocol filters | 进程与主机完整性、智能体工具调用与能力完整性、内部上游服务 | likely | unmitigated | 仅 alpha 标签；无 fuzz target | — |
| T5 | 证书校验边界情况导致 mTLS/TLS 身份仿冒 | remote_unauth | TLS 握手与证书校验 | mTLS 工作负载身份、内部上游服务 | possible | partially_mitigated | BoringSSL、SPIFFE validator、SAN matchers | CVE-2025-66220、CVE-2023-0286 |
| T26 | 畸形 ext_proc/ext_authz gRPC 响应经mutation_utils应用导致内存破坏或崩溃 | adjacent_network | ext_proc/ext_authz 响应 | 进程与主机完整性 | possible | unmitigated | 无（该路径按可信输入编写，无 fuzz target） | — |
| T28 | 恶意服务器响应导致 Envoy Mobile 客户端 RCE 或数据外泄 | remote_unauth | Envoy Mobile 上游摄取 | 移动应用进程与设备数据 | possible | partially_mitigated | 共享加固核心 codec；iOS/Android 进程沙箱 | — |
| T8 | pull_request_target信任标志混淆或 toolshed-action 沦陷导致 CI 机密外泄与签名发布接管 | supply_chain | GitHub Actions CI | CI/发布机密、发布产物完整性 | possible | partially_mitigated | actions SHA 固定（一处例外）；external-contributorsenv 门控；_load.yml的trusted标志 | — |
| T9 | 经 EngFlow 远程构建缓存投毒导致恶意发布产物 | supply_chain | GitHub Actions CI、Bazel 依赖获取 | 发布产物完整性 | rare | partially_mitigated | EngFlow 租户 ACL（tree 外）；Bazel action 哈希 | — |
4.2 High 级威胁
| ID | 威胁 | 攻击者 | 攻击面 | 影响 | 可能性 | 状态 | 控制 | 证据 |
|---|---|---|---|---|---|---|---|---|
| T11 | Envoy 与上游间 HTTP/1 解析差异导致请求走私/缓存投毒 | remote_unauth | HTTP/1 codec、上游响应路径、Header 与路径归一化 | 被代理数据、AuthN/AuthZ 裁决、内部上游服务 | almost_certain | partially_mitigated | Balsa parser；严格 header 检查（操作者可配置） | CVE-2019-9900、CVE-2019-18802、CVE-2024-45809、CVE-2024-34363、CVE-2023-35944、CVE-2025-64763、CVE-2020-25018 |
| T10 | 构造的 HTTP/2 帧序列导致 CPU/内存资源耗尽 | remote_unauth | HTTP/2 codec、TCP listener | 服务可用性 | almost_certain | partially_mitigated | protocol_constraints.cc flood 限制；过载管理器（操作者配置，默认关闭） | CVE-2024-30255、CVE-2023-44487、CVE-2020-11080、CVE-2020-12603/04/05、CVE-2023-35945、CVE-2026-27135 |
| T12 | 路径归一化或 matcher 边界情况导致路由/RBAC 策略绕过与 SSRF 到内部服务 | remote_unauth | Header 与路径归一化、路由匹配与正则 | 内部上游服务、AuthN/AuthZ 裁决 | likely | partially_mitigated | normalize_path、merge_slashes、path_with_escaped_slashes_action（操作者配置） | CVE-2019-9901、CVE-2023-27487、CVE-2020-25017 |
| T13 | 解压炸弹或转码放大导致内存/CPU 耗尽 | remote_unauth | 解压与转码 | 服务可用性 | likely | partially_mitigated | 各解压器输出大小限制（CVE 后新增）；buffer 水位线 | CVE-2022-29225、CVE-2024-32475 |
| T14 | 恶意 DNS 响应导致内存破坏或集群端点投毒 | adjacent_network | DNS resolver（客户端） | 进程与主机完整性、内部上游服务 | likely | partially_mitigated | c-ares 上游维护；hickory（Rust）替代方案 | GHSA-fg9g-pvc4-776f、CVE-2025-31498、CVE-2023-32067、CVE-2023-31147、GHSA-g9vw-6pvx-7gmw |
| T15 | 恶意上游响应导致崩溃、内存破坏或响应走私 | remote_auth | 上游响应路径 | 进程与主机完整性、被代理数据、服务可用性 | likely | partially_mitigated | 核心声明对不可信上游健壮；与下游相同的 codec 加固 | CVE-2022-29224、CVE-2023-35945、CVE-2024-45809、CVE-2024-34364 |
| T18 | 不可信 ext_proc/ext_authz 边调用导致请求/响应篡改与认证裁决伪造 | adjacent_network | ext_proc/ext_authz 响应 | 被代理数据、AuthN/AuthZ 裁决、内部信任头 | likely | partially_mitigated | mutation_rules白名单（opt-in）；ext_authz 的allowed_headers/disallowed_headers（opt-in） | — |
| T27 | 无界 ext_proc body 变更、header 集合大小或流保持打开导致资源耗尽 | adjacent_network | ext_proc/ext_authz 响应 | 服务可用性 | likely | partially_mitigated | message_timeout；按消息大小限制（部分） | — |
| T16 | 畸形/病态 xDS 配置导致全舰队崩溃或资源耗尽 | insider | xDS 控制平面摄取、路由匹配与正则 | 服务可用性、xDS 配置完整性 | likely | partially_mitigated | PGV proto 校验；配置拒绝统计；RE2（线性时间）正则 | a20c0ab8dd、2bcebccc0d、CVE-2019-15225、CVE-2019-15226 |
| T17 | 经篡改 OCI 镜像（无签名/无 SLSA provenance）导致下游消费者沦陷 | supply_chain | 发布产物发布 | 发布产物完整性 | possible | unmitigated | 仅 tarball 有 GPG；--sbom=false --provenance=false；无 cosign | — |
| T19 | 被攻陷的 xDS 管理服务器导致流量重定向或 filter-chain 注入 | insider | xDS 控制平面摄取 | xDS 配置完整性、被代理数据、内部上游服务 | possible | risk_accepted | 上游威胁模型声明 xDS 传输可信；到控制平面用 mTLS | — |
| T20 | 被攻陷的上游依赖 tarball 导致构建期代码注入 | supply_chain | Bazel 依赖获取 | 发布产物完整性、进程与主机完整性 | rare | mitigated | 全部 113 个依赖 SHA256 固定；tools/dependency/ 校验器；CPE 追踪 | — |
4.3 Medium / Low 级威胁
| ID | 威胁 | 攻击者 | 攻击面 | 影响 | 可能性 | 状态 | 控制 | 证据 |
|---|---|---|---|---|---|---|---|---|
| T21 | 访问日志输出中未转义攻击者控制字段导致日志注入 / SIEM 投毒 | remote_unauth | Access-log formatter | 访问日志与遥测 | likely | partially_mitigated | json_format转义；JsonEscaper（自身曾因 OOB 打补丁） | CVE-2024-45808、CVE-2026-26309 |
| T22 | 租户提供的正则针对攻击者输入求值导致 CPU 耗尽（多租户 xDS） | remote_unauth | 路由匹配与正则、xDS 摄取 | 服务可用性 | possible | partially_mitigated | RE2 默认（线性）；程序大小限制；std::regex已移除 | CVE-2019-15225 |
| T25 | Envoy QUIC 或 DNS UDP 监听器被用于对第三方反射/放大攻击 | remote_unauth | UDP/QUIC 摄取、DNS UDP filter | 服务可用性 | possible | partially_mitigated | quiche 内 QUIC Retry/放大限制；DNS filter 响应大小上限 | — |
4.4 威胁模式解读：三大历史主旋律
对照 threat_model.rst 与源码可以归纳出历史 CVE 的三个主要模式，这也是威胁清单中"证据"列高度聚集的区域：
- HTTP/2 帧处理 DoS（T10）：从 CVE-2020-11080 到 CVE-2023-44487（Rapid Reset），flood 限制沉淀在 protocol_constraints.cc，但过载管理器仍默认关闭，需要操作者显式开启；
- HTTP filter-chain 生命周期 use-after-free（T1）：流重置与异步回调竞争是核心成因，缓解方向是统一 deferred-stream-destruction / weak-ref 惯用法；
- authn/authz 过滤器绕过（T2）：JWT/OAuth2 解析、header 处理与路径归一化的边界情况是重灾区，缓解方向是严格默认的 HCM header 校验。
五、降级项（Deprioritized）：明确"不在此模型范围内"的边界
威胁模型还明确列出不建模的项及其理由，避免安全投入发散：
| 威胁 | 排除理由 |
|---|---|
| Admin HTTP 接口（进程控制/信息泄露） | 按上游威胁模型 admin 端点仅操作者可信任；暴露是部署配置错误而非 Envoy 缺陷 |
| Wasm / Lua / 动态模块宿主 ABI（沙箱逃逸） | 按上游模型模块代码可信，沙箱明确不是安全边界；相关运行时 CVE（CVE-2023-26489、CVE-2023-27477、CVE-2024-25176/77/78、CVE-2025-53901）按依赖卫生追踪而非建模威胁 |
| CLI / 环境变量（经进程环境提权） | 进程启动者（编排器/操作者）可信，无特权边界跨越 |
| Hot-restart UDS（同 netns 进程窃取 FD/状态） | 同网络命名空间本地进程可信；隔离边界是 netns 而非 abstract socket |
| Bootstrap 与文件配置（经配置路径任意文件读取） | 按上游模型配置作者可信 |
contrib/与 alpha 扩展（MCP/A2A 除外） | 在 EXTENSION_POLICY.md 定义的上游安全团队覆盖之外；含 Postgres/MySQL/Kafka/SIP/RocketMQ/Go-filter 解析器 |
| Windows 专属代码路径 | 按负责人指示不在范围内 |
| 被代理请求的不可否认性 | Envoy 不是不可否认性的记录系统；访问日志是资产（§2），但密码学不可否认性不在范围内 |
| TLS 私钥的侧信道/时序攻击 | BoringSSL 的责任；继承其恒定时间保证 |
| 硬化组件上低于 100× 放大的 DoS | 上游明确不将低于阈值的 DoS 视为安全问题；操作者须配置过载管理器 |
六、推荐缓解措施（Recommended Mitigations）
威胁清单的"控制"列显示大量威胁仍处于 partially_mitigated 或 unmitigated 状态，因此模型给出了一个按"威胁 ID → 关闭类别 → 投入"组织的缓解路线图：
| 缓解措施 | 关联威胁 | 关闭类别 | 投入 |
|---|---|---|---|
在所有异步 filter 回调中采用统一的 deferred-stream-destruction / weak-ref 惯用法；为 posted callbacks 中裸this捕获新增 clang-tidy 检查 | T1 | partial | L |
| 严格默认的 HCM header 校验（拒绝重复的认证相关头、拒绝 CL+TE 冲突、拒绝内嵌 NUL/CR/LF），不依赖 UHV | T2、T11 | partial | M |
将normalize_path/merge_slashes/path_with_escaped_slashes_action: REJECT_REQUEST设为安全默认 | T12 | partial | S |
任何 L7 codec 从 alpha 毕业前要求robust_to_untrusted_downstreamposture + fuzz target | T3、T29 | partial | M |
| 将过载管理器与 HTTP/2 flood 限制作为默认开启的安全基线而非操作者 opt-in | T10、T13、T22 | partial | M |
将 ext_procmutation_rules改为 deny-by-default；为ProcessingResponse/CheckResponse应用路径新增 fuzz target | T18、T26、T27 | partial | M |
用结构化序列化器替换mcp_router中的StrCatJSON 构造；为mcp_json_parser/a2a_json_parser及后端响应合并路径新增 fuzz targets | T29 | partial | M |
| 默认 DNS resolver 从 c-ares 迁移到 hickory（Rust）或本地 stub 后的 getaddrinfo | T14 | partial | M |
用 cosign 签名 OCI 镜像并生成 SLSA provenance；SHA 固定pypa/gh-action-pypi-publish；GCP 认证迁移到 WIF/OIDC | T8、T17 | partial | S |
将发布构建与 PR 触发的缓存写入隔离（独立 EngFlow 缓存命名空间或对不可信构建用--noremote_upload_local_results） | T9 | yes | S |
| 在所有解压器与 gRPC-JSON 转码器上，将解压输出硬上限设为输入的比例 | T13 | yes | S |
对所有 formatter 展开字段按汇语法转义/校验（文本用 newline-strip，json_format用完整 JSON 转义） | T21 | yes | S |
其中"关闭类别"为yes的三项（T9 缓存隔离、T13 解压比硬上限、T21 日志字段转义）是可以完整闭环的缓解；其余为 partial（部分缓解）。投入列 S/M/L 表示单次修复的小/中/大工作量。
值得特别关注的三项 unmitigated 威胁：
- T29（MCP/A2A，critical + likely + unmitigated）：对应缓解项明确要求为
mcp_json_parser/a2a_json_parser与后端响应合并路径新增 fuzz targets，并替换mcp_router中基于StrCat的 JSON 拼接——这印证了前文 §3 中 MCP/A2A 过滤器"两端均不可信"的边界设计； - T26（ext_proc/ext_authz 畸形响应，critical + possible + unmitigated）：与本模型唯一的 owner-directed divergence 直接相关——将边调用响应视为不可信后，
mutation_utils应用路径的加固与 fuzz 成为必要； - T17（镜像无签名/无 provenance，high + possible + unmitigated）：属于供应链，缓解项为 cosign 签名与 SLSA provenance 落地。
七、结语：如何使用这份威胁模型
这份威胁模型是 Envoy 操作者、开发者与安全研究者的核心参考。使用时建议遵循以下路径：
- 先读上游官方模型threat_model.rst，理解官方对机密性/完整性/可用性的分级触发条件、数据平面与控制平面划分，以及"核心硬化、alpha 不受保"的总体姿态；
- 对照本文档的资产清单（§2）识别你部署形态中最敏感的资产——边缘代理形态聚焦进程完整性与服务可用性，网格 sidecar 形态叠加 mTLS 身份与内部上游服务，Envoy Mobile 形态则要反转信任模型看待恶意服务器；
- 用入口点表（§3）做攻击面盘点，尤其检查你是否开启了 MCP/A2A 过滤器（T29 无缓解）、ext_proc/ext_authz（T18/T26/T27，按不可信假设部署）、QUIC/DNS UDP 监听（T4/T25）以及默认关闭的过载管理器（T10）；
- 按缓解路线图（§6）排期：优先落实三项可闭环项（镜像签名、解压比上限、日志转义），再推进 partial 项中的 MCP/A2A fuzz 覆盖与 ext_proc 默认拒绝策略。
正如上游官方模型所强调的：默认配置下的 Envoy 不具备可用性层面的安全默认值，安全姿态的落地依赖操作者的显式配置与持续投入，而这份威胁模型正是把投入导向最高风险资产的路线图。
【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
