#对消费者进行身份验证

#使用 OIDC 或 JWT 进行身份验证

验证由 OIDC issuer 签发的 token。平台内置的 Dex 是默认 issuer；它还可以代理外部身份来源，例如 LDAP 或其他 OIDC provider，以便这些用户获取平台 token。这些连接器在平台 IdP (Identity Provider) 管理中进行配置。有关平台 IdP 配置，请参阅 Identity Providers。

任何具有可访问 JWKS 端点的 OIDC issuer 都可以使用。当消费者不是平台用户时，请将下面的 issuer 和 remoteJWKS.uri 替换为你选择的 issuer，例如企业 Keycloak realm 或 SaaS IdP，这样网关就能接受其 token，而无需平台账户。

将网关指向 OIDC issuer，并将其 claim 映射到身份请求头：

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: maas-oidc-auth
  namespace: <your-namespace>
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: <aigatewayroute-name>  # HTTPRoute generated by your AIGatewayRoute
  jwt:
    providers:
      - name: platform-idp
        issuer: https://<platform-address>/dex
        audiences:
          - <gateway-client-id>   # reject tokens minted for other clients of the same issuer
        remoteJWKS:
          uri: https://<platform-address>/dex/keys
        claimToHeaders:
          - claim: sub      # caller identity, used as the per-user quota and metering key
            header: x-user-id
          - claim: groups    # single-valued group/department claim (see note: array claims are unsupported)
            header: x-user-group
          - claim: namespace  # custom scalar claim for per-namespace chargeback; absent by default (see note)
            header: x-user-namespace
          - claim: email
            header: x-user-email

• <platform-address>：平台访问地址。Dex 将其 issuer 发布在 /dex，JWKS 发布在 /dex/keys。
• <aigatewayroute-name>：由你的 AIGatewayRoute 生成的 HTTPRoute 名称。
• audiences：网关接受的 token audience。对于共享 IdP，如果省略此项，则会接受来自同一 issuer 的任何有效 token——包括为其他客户端签发的 token——这些 token 仍然会解析为 x-user-id 并消耗配额。请将其设置为网关 token 签发所针对的 client ID；如果你的 issuer 未设置可区分的 aud，请为网关注册一个专用 client。
• claimToHeaders：身份与策略之间的桥梁。生成的请求头（x-user-id、x-user-group、x-user-namespace）会成为 token 配额的选择器键，以及使用量计量和 chargeback 的标签值。

#使用 API key 进行身份验证

对于无法执行 OIDC 流程的机器消费者，请改用静态 API key 进行验证。这里没有签发服务：集群管理员为每个消费者生成一个随机字符串，将其存储在 Secret 中，并通过带外方式共享。网关的数据平面通过在该 Secret 中查找所提供的值来验证每个请求。

为每个消费者生成一个 key，并将它们存储在同一个 Opaque Secret 中。每个 data-map key 都是下游策略看到的客户端标识符；每个 value 都是消费者提供的API key：

kubectl -n <your-namespace> create secret generic maas-api-keys \
  --from-literal=alice="$(openssl rand -hex 32)" \
  --from-literal=ci-runner="$(openssl rand -hex 32)"

使用 SecurityPolicy 将该 Secret 绑定到路由：

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: maas-apikey-auth
  namespace: <your-namespace>
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: <aigatewayroute-name>  # HTTPRoute generated by your AIGatewayRoute
  apiKeyAuth:
    credentialRefs:
      - name: maas-api-keys     # Secret whose data keys are the client identifiers
    extractFrom:
      - headers:
          - X-API-Key           # dedicated header avoids the "Bearer " prefix problem of Authorization
    forwardClientIDHeader: x-user-id  # matched client identifier is injected as this header for downstream policies
    sanitize: true              # strip the raw API key from the request before it reaches the model backend

• credentialRefs：一个或多个保存凭证的 Opaque Secret。每个 data-map key 都是客户端标识符，每个 value 都是字面量 API key。添加消费者只需对一个条目执行 kubectl patch；撤销则只需删除一个 key。
• extractFrom：Envoy 从哪里读取所提供的 key。该过滤器执行字面字符串比较，因此建议使用专用请求头，例如 X-API-Key。复用 Authorization 需要将 value 及其 Bearer 前缀一并存储，这与同一网关上的 OIDC 路径会产生冲突。
• forwardClientIDHeader：将匹配到的客户端标识符传递给上游以及后续过滤器的请求头。请使用与 OIDC claimToHeaders 目标相同的名称（x-user-id），这样 token 配额和使用量计量在两条认证路径上就能看到一致的 key。
• sanitize：防止原始 API key 泄漏到模型后端或在下游日志中被记录。

如果网关必须保留在 envoy-gateway-system 中，则 apiKeyAuth 的强制执行会受到上述相同控制平面 listener-skip 的影响，并且没有任何按路由的 SecurityPolicy 更改可以修复它。受支持的修复方案是将 Gateway 和 AIGatewayRoute 移动到专用命名空间（首选），或者将 Envoy AI Gateway 升级到一个缩小 listener-skip 范围的版本（v0.6.0 / Alauda release-0.6.0-alauda）。手工编写的 EnvoyPatchPolicy 也许可以作为临时权宜之计，通过修改监听器过滤器链来实现，但它具有版本相关性且较为脆弱——它依赖于运行中的 Envoy 构建的精确过滤器布局——因此不建议用于生产环境。