【Envoy 数据面】扩展边界：Wasm / Lua / ext_authz / Rate limit 挂在哪一层
内容提要
本文介绍Envoy数据面代理的扩展机制，涵盖Wasm、Lua、ext_authz和限流过滤器。Wasm提供沙箱隔离但属实验特性；Lua适合可信粘合逻辑但需防路由缓存绕过鉴权；ext_authz将决策移至外部服务；限流分本地和全局两种。选型需权衡隔离性、延迟和信任域，热点路径慎用Wasm。
延伸解读
扩展挂点决定安全边界
Envoy 扩展并非随意插入，而是按事件模型分层：Network filter 处理连接字节流，HTTP filter 链处理已解码请求，Router 之后及进程外调用各有对应位置。鉴权若放在可能改路由的过滤器之后，会引入先定路由再鉴权或清 route cache 后绕过鉴权的风险。选型前应先明确扩展挂点，再考虑实现语言，否则容易画歪安全边界。
Wasm 与 Lua 的信任域差异
Wasm 提供 VM 沙箱，适合运行不可全信的多租户逻辑，但仍是实验特性，热点路径慎用；Lua 无沙箱，与 Envoy 同信任域，适合运维可控的粘合逻辑。若将 Lua 放在 ext_authz 之后，clearRouteCache() 可能造成鉴权绕过，属于权限提升风险。因此，不可信代码应选 Wasm 或进程外服务，而非 Lua。
限流分层：本地止血与全局配额
本地限流在进程内令牌桶，适合单实例过载保护，但无法跨实例精确配额；全局限流依赖外部服务，支持多实例协同，但引入可用性与延迟耦合。两者可叠加：本地做紧急止血，全局做租户级配额。选型时需权衡简单可靠与配额准确，算法细节见 architecture/25。
ext_authz 的故障模式与顺序安全
ext_authz 将鉴权决策移至外部服务，策略可独立于 Envoy 发布，但带来同步依赖：鉴权服务超时或错误时，需通过 failure_mode_allow 等配置决定 fail-open 或 fail-closed。同时必须注意与后续清 route cache 的过滤器顺序，推荐用 ExtensionWithMatcher 做条件启用，避免仅依赖 metadata 开关。
Q&A
Envoy 中 Wasm、Lua、ext_authz 和限流过滤器分别挂在哪个处理层？
它们主要挂在 HTTP filter 链上，处理已解码的请求/响应。其中 ext_authz 和全局 rate limit 还会调用进程外的 gRPC/HTTP 服务。
Envoy 的 Wasm 过滤器有什么优缺点？适合在什么场景下使用？
Wasm 过滤器提供沙箱隔离，但标记为实验特性，不适合热点路径。适合在代理进程内运行不可全信的逻辑，但需注意 ABI 稳定性、延迟和运维不确定性。
Envoy 的 Lua 过滤器有什么安全风险？如何避免鉴权绕过？
Lua 过滤器无沙箱，与 Envoy 同信任域，适合可信粘合逻辑。风险在于 clearRouteCache() 等 API 可能改变路由匹配，若放在 ext_authz 之后可能导致鉴权绕过。应避免在 ext_authz 之后使用 clearRouteCache()，或调整过滤器顺序。
ext_authz 过滤器的作用是什么？它有哪些失败模式？
ext_authz 将鉴权决策移至外部服务，通过 CheckRequest 调用外部 gRPC/HTTP 服务决定放行或拒绝。失败模式由 failure_mode_allow 等配置决定，可设置为 fail-open 或 fail-closed。
Envoy 的本地限流和全局限流有什么区别？分别适用于什么场景？
本地限流在 Envoy 进程内使用令牌桶，适合单实例保护，但不能跨实例精确配额。全局限流依赖外部 Rate Limit Service，支持跨实例配额，但引入可用性耦合。可叠加使用：本地做紧急止血，全局做租户级配额。
在 Envoy 中如何选择扩展机制？比如不可信多租户逻辑、强一致跨实例配额、单实例过载、独立演进鉴权分别该用哪种？
不可信多租户逻辑用 Wasm 或进程外服务，不要用 Lua；强一致跨实例配额用全局 rate limit；单实例过载用本地 rate limit；独立演进鉴权用 ext_authz，并注意与 route mutation 的顺序安全。
