Cilium 1.20 加入 Gateway API ExternalAuth 有何意义

Cilium 1.20 支持 Gateway API 的 ExternalAuth 过滤器，意义不只是“多了一个鉴权开关”。它把原本分散在应用代码、旁路代理或 Cilium 专有 Envoy 配置里的入口认证与授权委托，收敛为 HTTPRoute 规则的一部分：请求在进入业务 Service 之前，先由 Gateway 调用外部鉴权服务，再根据返回结果决定放行或拒绝。

Cilium 官方地址：https://cilium.io/

最值得关注的变化是职责边界：应用团队可以在路由规则上声明“这段流量需要外部鉴权”，平台团队负责鉴权服务、Gateway 数据面、TLS、容量和观测。它减少了专有配置，但也把鉴权服务变成入口链路上的关键依赖。

1.20 具体增加了什么

Cilium 1.20 的官方发布说明把 External Authorization 列为 Gateway API 增强项。HTTPRoute 可以使用 GEP-1494 定义的 ExternalAuth 过滤器，在请求抵达应用前，把认证和授权判断交给外部服务。

这项实现支持两种对接方式：

• gRPC：外部服务实现 Envoy ext_authz 协议，适合已有 Envoy 鉴权服务或需要结构化请求上下文的场景。
• HTTP：外部服务通过 HTTP 返回授权结果；Gateway API 规范规定成功授权使用 200，其他状态视为授权失败。

外部鉴权后端还能与请求头白名单、响应头传递、有限大小的请求体转发、路径前缀和 BackendTLSPolicy 配合。它没有规定必须使用哪一种身份系统，真正的 OAuth、JWT、会话、API Key 或组织策略仍由外部鉴权服务实现。

规模一大，旧做法的维护成本会暴露

小规模系统把鉴权写在每个应用里并不罕见，但服务数量增加后，同一件事会产生多套实现：不同语言使用不同中间件，令牌解析规则不一致，拒绝响应格式不同，更新策略时还要逐个应用发布。平台团队很难回答“哪些入口已经接入统一鉴权”和“某条路由是否漏掉策略”。

另一条路是直接写 CiliumEnvoyConfig 或其他实现专有的代理配置。它能控制 Envoy 的 ext_authz，但配置与具体数据面绑定，应用开发者通常也不应该直接维护底层 Envoy 过滤器。路由与鉴权的意图分散在不同资源中，迁移 Gateway 实现、升级配置模型和排查状态都会更复杂。

ExternalAuth 的价值在于把“哪条 HTTPRoute 规则需要鉴权”放回 Gateway API 资源里。它没有消除鉴权服务，也没有把安全问题自动解决；它减少的是应用与代理实现之间的耦合。

新架构把鉴权决策放到转发之前

请求链路可以拆成四个角色：客户端、Cilium Gateway、外部鉴权服务和业务 Service。Gateway 根据匹配到的 HTTPRoute 规则调用鉴权服务；鉴权服务检查请求上下文并返回允许或拒绝；只有允许的请求才继续转发到业务后端。

这里最关键的变化是，鉴权调用由 Gateway 执行，而不是由业务 Pod 在收到请求后执行。这样做有三点直接影响：

1. 未经允许的请求不会进入业务 Service，入口层可以统一拒绝。
2. 多种语言的应用可以复用同一个外部鉴权服务，不再各自实现协议适配。
3. 鉴权服务的延迟、错误率与容量会直接影响入口请求，必须按数据面关键依赖管理。

Cilium 的 Gateway API 数据面使用每节点 Envoy 处理 L7 流量，并与 Cilium 的 eBPF 网络和策略能力结合。ExternalAuth 仍属于这个 L7 请求处理路径，因此它不是纯控制面标签，而是会增加一次真实的鉴权调用。

最小 HTTPRoute 配置长什么样

下面是一个只展示关键字段的原创示例。它让 /api 路径在转发给 orders Service 前，先通过 gRPC 调用同命名空间的 authz Service：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders-route
spec:
  # 将这条路由附着到 Cilium 管理的 Gateway。
  parentRefs:
    - name: public-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      filters:
        # ExternalAuth 字段来自 Gateway API 实验通道。
        - type: ExternalAuth
          externalAuth:
            protocol: GRPC
            backendRef:
              # 该服务需要实现 Envoy ext_authz gRPC 协议。
              name: authz
              port: 9000
      backendRefs:
        # 只有鉴权允许后，请求才会进入业务后端。
        - name: orders
          port: 8080

backendRef 指向的是鉴权服务，不是最终业务 Service；真正的业务后端仍写在规则的 backendRefs 中。如果鉴权服务在其他命名空间，还要满足 Gateway API 的跨命名空间引用规则。鉴权后端需要 TLS 时，应使用 BackendTLSPolicy 描述 Gateway 到该后端的 TLS 连接。

这项字段目前属于 Gateway API 的实验通道，支持级别是 Extended，不是每个 Gateway 实现都必须支持的 Core 能力。Cilium 1.20 的升级文档要求 Gateway API 至少为 1.6.1；要使用 ExternalAuth，还要安装包含实验字段的 CRD，而不是只安装标准通道 CRD。

# 安装 Gateway API 1.6.1 的实验通道 CRD，ExternalAuth 字段才会出现在 HTTPRoute 中。
kubectl apply --server-side \
  -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.1/experimental-install.yaml

# 在 Cilium 1.20 系列中启用 Gateway API 控制器；保留现有集群的其他 Helm 配置。
cilium upgrade 1.20.2 \
  --set kubeProxyReplacement=true \
  --set gatewayAPI.enabled=true

版本号应以部署时 Cilium 1.20 系列的最新补丁版为准。升级前要按Cilium 官方升级指南保存原有 Helm values，不要为了启用 Gateway API 丢失已有配置。

收益来自职责标准化，代价也会集中到平台层

从应用团队视角看，收益是配置更贴近路由意图。团队不必理解 CiliumEnvoyConfig 的底层过滤器结构，只需在自己拥有的 HTTPRoute 规则上声明外部鉴权，并选择平台提供的鉴权后端。相同策略也更容易在多条路由间复用。

从平台团队视角看，收益是能够统一管理鉴权服务、TLS、允许转发的请求头和可观测性。路由状态与 Gateway API 条件也提供了更标准的排查入口，而不是只在 Envoy 配置里寻找结果。

但集中化会带来明确代价：

上线判断不能只看配置被接受

Gateway API 规范要求 ExternalAuth 与外部服务通信出现问题时失败关闭。这是更安全的默认值，但也意味着鉴权服务、DNS、Service 端点、TLS 和网络策略任何一处故障，都可能表现为入口请求被拒绝。生产上线至少应完成以下检查：

• 版本与 CRD：Cilium 1.20、Gateway API 1.6.1 及实验 CRD组合正确，HTTPRoute 字段不会被 API Server 拒绝或裁剪。
• 路由状态：检查 HTTPRoute 的 Accepted、ResolvedRefs 和 Gateway 的 Programmed 条件，确认后端引用已解析。
• 失败场景：分别验证允许、明确拒绝、鉴权服务超时、无可用端点和 TLS 失败，确认系统不会在异常时绕过鉴权。
• 容量与延迟：以真实请求头和请求体策略压测鉴权服务，观察高分位延迟、错误率、连接数和 Gateway 资源。
• 敏感信息：只把鉴权所需请求头交给外部服务，谨慎启用请求体转发，并限制最大体积。
• 回滚路径：先在单独的 hostname 或路径灰度；回滚前确认移除过滤器不会把受保护接口直接暴露。

# 检查 Gateway 是否已由 Cilium 数据面编程完成。
kubectl get gateway public-gateway

# 查看 HTTPRoute 的 Accepted、ResolvedRefs 等条件，确认过滤器和引用已被控制器接受。
kubectl describe httproute orders-route

# 检查鉴权 Service 是否存在可用端点，避免失败关闭导致全部请求被拒绝。
kubectl get service,endpointslices -l kubernetes.io/service-name=authz

什么团队最适合优先采用

如果团队已经使用 Cilium Gateway API，并且拥有统一的 OPA、OAuth2 代理、自研 gRPC 鉴权服务或其他 ext_authz 兼容后端，ExternalAuth 很有吸引力。它能把应用入口策略从多语言中间件和专有代理配置中抽离出来，特别适合多团队共享平台。

如果组织还没有高可用鉴权服务、缺少 Gateway 层的延迟与错误观测，或者不能接受实验性 CRD 带来的升级约束，就不应只因为 Cilium 1.20 提供了字段而立即全量切换。更稳妥的路径是选一条低风险 HTTPRoute 灰度，先验证状态、失败关闭和容量，再扩大范围。

因此，Cilium 1.20 的 ExternalAuth 更像一次架构接口标准化：鉴权仍由专门系统完成，Cilium 负责把这项决定接入 Gateway 请求路径，Gateway API 负责用可移植的资源模型表达意图。它减少了重复实现，却不会消除运行复杂度；真正决定采用价值的，是平台是否准备好承担这条新关键依赖。