Cilium 1.20 Gateway API 外部认证的工程影响

Cilium 1.20 对 Gateway API 的一个重要变化，是 HTTPRoute 可以通过 GEP-1494 的 ExternalAuth 过滤器，把请求交给独立服务完成认证和可选授权，再决定是否送往应用后端。工程上的影响很直接：平台团队终于可以用 Gateway API 对象描述这层能力，但认证服务的可用性、权限、TLS、状态检查和故障策略也一起进入网关的关键路径。

官方发布地址：https://github.com/cilium/cilium/releases/tag/v1.20.0

这不是“开启一个开关就自动拥有统一身份平台”。它把外部认证接入从 Cilium 专有 Envoy 配置向 Gateway API 的 HTTPRoute 过滤器推进了一步，同时仍属于实验性、扩展支持能力，应该按平台变更而不是普通路由字段变更来上线。

这项能力到底改变了什么

我把 Cilium 1.20 发布说明和 Gateway API 的 GEP-1494 放在一起看，最有价值的变化不是出现了一个新字段，而是责任边界变得更清楚。过去要在 Cilium 网关前接外部认证，团队往往需要维护实现专有的 Envoy 配置，或者在每个应用里重复接入认证中间件。现在，HTTPRoute 规则本身可以声明 ExternalAuth，把匹配到该规则的请求送往 HTTP 或 gRPC 认证服务。

Cilium 1.20 发布说明明确列出两种协议：HTTP，以及 Envoy ext_authz gRPC 协议。Gateway API 规范还给出了允许传入认证服务的请求头、允许带回的响应头、HTTP 路径前缀、请求体转发和认证后端引用等结构。若认证后端需要 TLS，可以通过 BackendTLSPolicy 描述网关到认证服务的信任关系。

这带来的好处是应用后端不必知道 Cilium 如何生成 Envoy 配置，只需接受经过网关认证后的流量与必要身份头。但这也意味着：一旦规则启用 ExternalAuth，认证服务就和 Gateway、路由状态、后端 Service 一样，成为请求成功率的一部分。

最容易误解的三个地方

ExternalAuth 不等于 Cilium 替你实现登录

网关负责把请求细节转交给外部服务，并根据它的决策放行或拒绝。OAuth、JWT、会话、租户、角色和业务权限仍由认证或授权服务实现。Cilium 提供的是标准化接入点，不是身份数据源，也不是完整的账户系统。

HTTPRoute 是正式资源，不代表每个过滤器都已稳定

HTTPRoute 本身属于 Gateway API 的标准通道，但 ExternalAuth 在 API 参考中仍标记为 Experimental，支持级别是 Extended。这意味着安装的 Gateway API CRD 必须包含相应实验性字段，具体实现也要明确宣告支持。只看“HTTPRoute 已经 GA”就把该过滤器当作核心兼容能力，会低估升级和回滚风险。

它保护的是已经匹配到规则的请求

ExternalAuth 挂在 HTTPRoute 规则上，规则先根据主机名、路径或请求条件完成匹配，随后过滤器才处理该请求。它不是一个天然覆盖所有 Gateway 与所有路由的全局认证策略。公共路径、健康检查、管理接口和未绑定该过滤器的路由，都需要单独盘点。

平台边界会如何重画

对我来说，这个变化最值得关注的是团队协作，而不是 YAML 行数。采用 ExternalAuth 后，至少会形成三种职责：

这种划分比“每个应用复制一套认证中间件”更集中，也比“平台团队维护一份没人敢改的 Envoy 配置”更贴近 Kubernetes 对象模型。不过，集中不代表简单。谁能引用认证 Service、谁能决定转发哪些请求头、身份结果是否允许覆盖已有头，都应该进入平台政策。

当 HTTPRoute 与认证 Service 位于不同命名空间时，还要处理 ReferenceGrant。它的意义不是补一个权限字段，而是让认证服务所属命名空间显式接受来自路由命名空间的引用。没有这层授权，平台不应通过放宽 RBAC 或把所有对象塞进同一命名空间来绕过边界。

工程收益与新增成本

ExternalAuth 最明显的收益，是把认证前置到共享流量入口，并让路由级配置更接近 Gateway API。统一的认证服务可以减少各语言框架重复实现令牌解析、错误响应和头部映射的差异。HTTP 与 gRPC 两种后端协议也给了团队迁移空间：简单服务可以先走 HTTP，已有 Envoy ext_authz 生态的团队可以使用 gRPC。

但我不会只因为“更标准”就立即迁移。下面这些成本会真实出现：

• 延迟：每个受保护请求增加一次认证调用，认证服务的网络位置和连接复用会直接影响尾延迟。
• 容量：网关可以横向扩展时，认证服务也必须按相同峰值与突发量规划，否则它会成为新的共享瓶颈。
• 请求体：规范允许配置请求体转发，但需要缓冲并设置最大尺寸；这会带来内存、隐私和大请求拒绝策略。
• 头部边界：允许送往认证服务和允许带回应用的头应该最小化，避免把 Cookie、内部令牌或可伪造身份头无差别透传。
• TLS：认证后端如果使用 TLS，证书名称、CA、轮换和 BackendTLSPolicy 都要纳入运维。
• 可观测性：必须区分路由未匹配、认证拒绝、认证服务不可达、超时、TLS 失败和应用后端错误。

这里有个经常被忽略的个人判断：如果应用仍会直接暴露其他入口，那么网关层认证只能保护经过该 Gateway 的流量。要么通过网络策略和 Service 暴露方式收紧旁路，要么在应用侧保留必要的身份校验，不能因为启用了 ExternalAuth 就默认内部流量全部可信。

上线前必须完成的验证

ExternalAuth 属于安全关键路径，我更倾向于用“故障优先”的验收顺序。先验证认证服务不可用时发生什么，再验证正常登录。Gateway API 规范明确要求：与外部认证服务通信出现问题时应当故障关闭，不能静默放行到应用。

一套最小上线清单可以包括：

1. 确认安装的是包含 ExternalAuth 字段的 Gateway API 实验性 CRD，并记录 CRD 与 Cilium 的版本组合。
2. 检查 HTTPRoute 的 Accepted、ResolvedRefs 等状态条件，确保认证后端引用被实现接受。
3. 分别验证有效凭据、无凭据、无效凭据、认证服务拒绝、认证服务超时和认证 Service 不存在。
4. 若跨命名空间引用认证 Service，确认 ReferenceGrant 只开放需要的来源与目标。
5. 若启用后端 TLS，验证正确证书、错误证书、过期证书和名称不匹配时的行为。
6. 核对允许请求头和响应头清单，确认客户端不能绕过网关伪造应用信任的身份头。
7. 为认证服务设置独立容量告警，并在访问日志和指标中区分拒绝、错误与超时。
8. 准备回滚后的保护措施，避免删除过滤器后路由意外变成匿名公开。

Cilium 1.20 的早期候选阶段曾出现过错误配置下请求被放行的报告，随后相关问题被修复并进入正式版本。这个历史提醒很具体：正式发布说明是功能存在的依据，但环境验收仍应以实际安装版本、CRD、HTTPRoute 状态和故障注入结果为准，不能只看配置是否被 API Server 接受。

哪些团队适合现在采用

如果团队已经运行 Cilium Gateway API，有成熟的认证服务，也能维护实验性 Gateway API CRD 与版本兼容矩阵，那么 ExternalAuth 值得在非核心流量或少量路由上先行。它能减少实现专有配置，让应用团队用熟悉的 HTTPRoute 表达认证需求。

如果团队缺少统一认证服务、没有网关故障注入、无法观察 HTTPRoute 状态，或者必须保证跨实现可移植性，我会建议暂缓全量迁移。Extended Support 代表实现可以支持，不代表所有 Gateway 实现都保证一致行为；Experimental 也意味着 API 仍可能变化。

比较稳妥的采用路径是：先选择一个独立域名和少量只读接口，限定头部和请求体，建立 fail-closed 测试与回滚保护，再逐步扩大范围。对于高风险写接口、管理接口和涉及敏感身份信息的路径，应在平台、身份和应用三方共同完成威胁建模后再切换。

延伸问题

ExternalAuth 能完全替代应用内授权吗？

通常不能。网关适合做统一认证和粗粒度授权，应用仍更了解资源所有权、业务状态和字段级权限。二者应明确分层，而不是把所有业务决策塞进认证服务。

应该选 HTTP 还是 gRPC 认证后端？

已有 Envoy ext_authz 生态、需要严格接口定义和高吞吐时可优先评估 gRPC；希望快速接入简单服务时可以评估 HTTP。最终选择应由延迟、工具链、错误语义和团队维护能力决定。

为什么要特别关注响应头？

认证服务可能把用户标识、角色或令牌信息放入响应头交给应用。若允许清单过宽，客户端原始头与认证结果的覆盖关系不清晰，就可能形成身份混淆。只转发应用真正需要且由网关可信生成的头。

升级到 Cilium 1.20 后会自动启用吗？

不会。还需要兼容的 Gateway API CRD、已启用的 Gateway API 能力、有效的 HTTPRoute ExternalAuth 配置、可解析的认证后端和必要的权限与 TLS 策略。