如何确保Istio中ext_authz EnvoyFilter先于AuthorizationPolicy执行？

你的问题核心是Istio默认的RBAC过滤器（对应AuthorizationPolicy）执行顺序早于你自定义的ext_authz过滤器，导致AuthorizationPolicy检查请求头时，oauth2-proxy还没完成认证并注入x-auth-request-user等头，规则直接触发DENY。

你当前的EnvoyFilter是把ext_authz插在router过滤器之前，但Istio的RBAC过滤器（envoy.filters.http.rbac）是在router之前、自定义过滤器之前执行的。所以需要把ext_authz插在RBAC过滤器之前，保证认证完成后再执行授权检查。

修改你的EnvoyFilter的HTTP_FILTER部分：

- applyTo: HTTP_FILTER
  match:
    context: SIDECAR_INBOUND
    listener:
      portNumber: 5678 # 这里要填Pod的容器端口，不是Service端口
      filterChain:
        filter:
          name: envoy.filters.network.http_connection_manager
          subFilter:
            name: envoy.filters.http.rbac # 改为匹配RBAC过滤器，插在它前面
  patch:
    operation: INSERT_BEFORE
    value:
      name: envoy.ext_authz
      typedConfig:
        "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
        # 其他配置保持不变...

注意：portNumber必须填Pod容器暴露的端口，而非Service端口，否则EnvoyFilter可能匹配不到正确的listener。

自定义EnvoyFilter维护成本高，Istio官方提供了更简洁的集成方式：

1. 使用Istio ExternalAuthorization CRD（替代自定义EnvoyFilter） #

Istio 1.10+支持通过AuthorizationPolicy结合externalAuthorization字段直接配置外部认证服务，无需手动编写EnvoyFilter，Istio会自动处理过滤器执行顺序：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: myapp-ext-authz
spec:
  selector:
    matchLabels:
      app: myapp
  action: CUSTOM
  provider:
    name: "oauth2-proxy-ext-authz"
  rules:
    - to:
        - operation:
            paths: ["*"]
---
apiVersion: extensions.istio.io/v1alpha1
kind: ExternalAuthorization
metadata:
  name: oauth2-proxy-ext-authz
spec:
  workloadSelector:
    labels:
      app: myapp
  server:
    service: oauth2-proxy.{{.Env.ARGOCD_ENV_NAMESPACE}}.svc.cluster.local
    port: 80
    timeout: 15s
  authorizationRequest:
    headersToAdd:
      - key: X-Auth-Request-Redirect
        value: "https://%REQ(Host)%%REQ(:PATH)%"
    allowedHeaders:
      patterns:
        - exact: cookie
        - exact: x-forwarded-access-token
  authorizationResponse:
    allowedUpstreamHeaders:
      patterns:
        - exact: authorization
        - exact: x-auth-request-user
        - exact: x-auth-request-email
    allowedClientHeaders:
      patterns:
        - exact: content-type
        - exact: set-cookie

2. 将认证移至网关层（更合理的架构） #

通常建议把认证逻辑放在入口Istio Gateway，而非每个应用的Sidecar：

• 在Istio Gateway上配置ext_authz过滤器指向oauth2-proxy
• 应用侧的AuthorizationPolicy直接基于网关传入的认证头做授权判断
  这种架构更清晰，避免重复配置，还能降低Sidecar的性能负担。

• 确认oauth2-proxy正确返回x-auth-request-user等头，且Istio通过authorizationResponse.allowedUpstreamHeaders配置允许这些头传递到应用侧
• 可以用istioctl pc filter <pod-name> -o yaml查看Sidecar的过滤器顺序，验证ext_authz是否在RBAC之前

内容的提问来源于stack exchange，提问作者Karl