Envoy 代理与安全特性归纳总结
做服务网格安全，逃不开 Envoy。它不是花架子，是真的站在你业务流量入口处干活的。我在落地 Istio 时遇到过一种情况：团队觉得安全策略就是写几条 yaml，结果生产上因为 mTLS 没配好，服务间调用直接挂了。说白了，Envoy 的安全能力需要你理解它的底层机制，才能驾驭。
这一章我把它归为：一条主线，五个模块。主线是 Envoy 怎么用 L4/L7 过滤器链构建安全防线；五个模块就是 TLS、RBAC、限流、外部认证和 JWT 验证。下面逐个拆开聊。
1. TLS 与 mTLS：最基础的信任
Envoy 支持双向 TLS，也就是 mTLS。我习惯把 mTLS 理解成「握手时互相掏身份证」。服务端要验证客户端证书，客户端也要验证服务端证书。这比单向 TLS 安全得多，因为它能防止恶意节点伪装成合法服务混入网格。
关键点：Envoy 的 mTLS 基于 SDS（Secret Discovery Service）动态获取证书。你不需要重启代理就能轮换证书，这在生产环境太实用了。我曾经因为证书过期导致整条链路中断过一个下午，后来全面切到 SDS 就再没出过这问题。
2. RBAC 过滤器：白名单与黑名单
Envoy 的 RBAC（Role Based Access Control）过滤器可以在 L4 和 L7 层面做访问控制。说白了就是：谁（主体）能对什么资源（路径/方法）做什么操作（动词）。
我习惯用白名单模式，先拒绝所有，再逐条放行。举个小例子：
filter_chains:
- filters:
- name: envoy.filters.http.rbac
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
rules:
action: ALLOW
policies:
"allow-admin":
permissions:
- header: { name: ":path", string_match: { prefix: "/admin" } }
principals:
- authenticated: { principal_name: { exact: "admin-cluster.local" } }
这个配置只允许带 admin 身份的服务访问 /admin 路径。其他的全干掉。嗯，这里要注意：RBAC 规则是按顺序匹配的，第一条匹配就停止。写混了会导致意想不到的放行。
3. 限流与熔断：保护下游不要被冲垮
Envoy 内置了限流（Rate Limiting）和熔断（Circuit Breaker）能力。限流是说“你每秒只能来 100 次”，熔断是说“如果后端连续失败 5 次，我就直接断开，等 30 秒再试”。
避坑指南：我曾经把限流阈值设得太紧，导致业务在白天高峰期大量 429 错误。后来分析发现，限流应该基于实际容量压测数据来设，不能拍脑袋。熔断的失败阈值建议从 10 次起步，太小的阈值容易误判短暂的雪崩。
限流配置通常配合全局限流服务（如 Envoy 的 Ratelimit 扩展），可以做到跨代理的分布式限流。
4. 外部认证：把鉴权交给专业的人
Envoy 的 ext_authz 过滤器允许你把认证逻辑委托给一个外部服务。这个外部服务可以是你的 OAuth2 网关，也可以是自定义的鉴权服务。配置时核心三个参数：
- grpc_service：外部鉴权服务的 gRPC 地址
- timeout：等多久认为超时（我建议 200ms，再久就会拖慢请求）
- failure_mode_allow：如果外部服务挂了，是放行还是拒绝？生产环境我选 false，安全优先。
5. JWT 验证：让业务代码不碰 JWT 逻辑
Envoy 原生支持 JWT 验证（envoy.filters.http.jwt_authn）。它可以在入口处解析 并验证签名，验证通过后再把 payload（如 uid、role）通过 header 传给后端服务。这样你的业务 Pod 就完全不用关心 JWT 库的版本、加密算法了。
个人习惯：我会在 Envoy 上先把 JWT 解码后的 claims 注入到 x-jwt-subject 和 x-jwt-role 两个自定义 header 里。后端只需要读 header，逻辑干净很多。注意签名算法，HS256 需要共享密钥，RS256 可以用公钥——后者在网格里更安全。
一张图看懂 Envoy 安全架构
下面这个 SVG 是我手绘的 Envoy 安全过滤器链流程。它从入站流量开始，依次经过 mTLS 握手、RBAC 检查、限流过滤、JWT 验证，最后到达外部鉴权服务。（注意：mTLS 发生在传输层，其他在 HTTP 过滤层）
核心安全特性速查表
我把上面五个模块整理成一个表格，方便你对照选择：
| 安全特性 | 过滤层 | 常用配置项 | 典型场景 |
|---|---|---|---|
| mTLS | 传输层 | SSL/TLS 插槽、SDS | 网格内服务间加密 |
| RBAC | L7 / L4 | permissions, principals | API 白名单、角色隔离 |
| 限流 | L7 | rate_limit_service | 防刷、流量整形 |
| 熔断 | L4 / 集群 | max_connections, circuit_breakers | 保护下游服务 |
| JWT | L7 | providers, rules | API 网关 验证 |
| ext_authz | L7 | grpc_service, timeout | 自定义鉴权（OAuth2等） |
别忘了：Envoy 的安全特性不是孤立的——它们按顺序执行。比如 JWT 验证一定要放在 RBAC 之前，否则未经验证的请求可能拿到错误的主体会导致 RBAC 决策出错。我记得有一次就是因为顺序搞反，导致所有带无效 JWT 的请求都被 RBAC 白名单放过了，排查了半天。
小结一下
Envoy 的安全防护，本质上是把传统 WAF 和网关的能力下沉到 Sidecar 中。你不需要每个业务 Pod 都写一遍鉴权逻辑，只用配置几个过滤器就能实现全局统一的安全策略。我个人建议你从 mTLS 和 RBAC 起步，它们是底线；业务量大了再逐步加入限流和 JWT 验证。别一上来就全堆上，容易翻车。