EnvoyFilter envoy.ext_authz not working with 1.5.1

1

We have been using the envoy.ext_authz EnvoyFilter along with oauth2_proxy on our Istio configurations for quite a while. This was however on version 1.4.5. We upgraded Istio to 1.5.1 and have not been able to get the EnvoyFilter to work. Ideally the filter redirects all incoming requests to oauth2_proxy which then handle authentication and forwards it to the required VirtualService. However, after the upgrade the redirect does not happen at all, and no incoming request is redirected to oauth2_proxy.

This is my EnvoyFilter

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: authn-filter
spec:
  workloadSelector:
    labels:
      app: istio-ingressgateway
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: GATEWAY
        listener:
          portNumber: 443
      patch:
        operation: INSERT_BEFORE
        value:
          name: "envoy.ext_authz"
          config:
            http_service:
              server_uri:
                uri: http://oauthproxy-service.oauth2-proxy.svc.cluster.local
                cluster: outbound|4180||oauthproxy-service.oauth2-proxy.svc.cluster.local
                timeout: 1.5s
              authorizationRequest:
                allowedHeaders:
                  patterns:
                  - exact: "cookie"
                  - exact: "x-forwarded-access-token"
                  - exact: "x-forwarded-user"
                  - exact: "x-forwarded-email"
                  - exact: "authorization"
                  - exact: "x-forwarded-proto"
                  - exact: "proxy-authorization"
                  - exact: "user-agent"
                  - exact: "x-forwarded-host"
                  - exact: "from"
                  - exact: "x-forwarded-for"
                  - exact: "accept"
                  - prefix: "x-forwarded"
                  - prefix: "x-auth-request"
              authorizationResponse:
                allowedClientHeaders:
                  patterns:
                  - exact: "location"
                  - exact: "proxy-authenticate"
                  - exact: "set-cookie"
                  - exact: "authorization"
                  - exact: "www-authenticate"
                  - prefix: "x-forwarded"
                  - prefix: "x-auth-request"
                allowedUpstreamHeaders:
                  patterns:
                  - exact: "location"
                  - exact: "proxy-authenticate"
                  - exact: "set-cookie"
                  - exact: "authorization"
                  - exact: "www-authenticate"
                  - prefix: "x-forwarded"
                  - prefix: "x-auth-request"

What could I be doing wrong, and how should I go about debugging this?

2 Likes
2

did you manage this find a solution for this?

3

I’ve had better luck when being explicit on the filter under the listener that I want to INSERT_BEFORE or INSERT_AFTER.

4

Anyone can share the solution? I have the same issue on 1.5.6

5

This works for me on 1.6:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: authn-filter
  namespace: istio-test
spec:
  workloadSelector:
    labels:
      app: httpbin
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      #context: GATEWAY
      listener:
        portNumber: 80
        filterChain:
          filter:
            name: "envoy.http_connection_manager"
            subFilter:
              name: "envoy.router"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.ext_authz
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.http.ext_authz.v2.ExtAuthz
          http_service:
            server_uri:
              uri: http://oauth2-proxy.istio-extensions.svc.cluster.local
              cluster: outbound|80||oauth2-proxy.istio-extensions.svc.cluster.local
              timeout: 3s
              #TODO below headers are probably more than needed. please trim down.
            authorization_request:
              #TODO below is a workaround to redirect back to the orignal url after authentication. this shound not be needed.
              headers_to_add:
              - key: x-auth-request-redirect
                value: "https://httpbin.dev.kube....com.au"
              allowed_headers:
                patterns:
                 - exact: "authorization"
                 - exact: "x-forwarded-proto"
                 - exact: "proxy-authorization"
                 - exact: "user-agent"
                 - exact: "x-forwarded-host"
                 - exact: "x-forwarded-proto"
                 - exact: "from"
                 - exact: "accept"
                 - prefix: "x-forwarded"
                 - prefix: "x-auth-request"
                 - prefix: "_oauth2_proxy"
                 - exact: "cookie"
                 - exact: "referer"                
                 - exact: "location"
                 - exact: "set-cookie"
            authorization_response:
              allowed_upstream_headers:
                patterns:
                  - exact: "authorization"
                  - exact: "Cookie"
                  - exact: "cookie"
                  - prefix: "_oauth2_proxy"
                  - exact: "location"
                  - exact: "proxy-authenticate"
                  - exact: "set-cookie"
                  - exact: "www-authenticate"
                  - prefix: "x-forwarded"
                  - prefix: "x-auth-request"
                  - exact: "referer"                
              allowed_client_headers:
                patterns:
                  - exact: "location"
                  - exact: "proxy-authenticate"
                  - exact: "set-cookie"
                  - exact: "authorization"
                  - exact: "www-authenticate"
                  - prefix: "x-forwarded"
                  - prefix: "x-auth-request"                
                  - exact: "referer"
6

Been digging through documentation trying to figure the same thing out on Istio 1.4.2 / Envoy 1.12.0 myself. Can’t upgrade due to old k8s.

I can’t figure out a typed_config: type that doesn’t result in Pilot’s webhook rejecting the EnvoyFilter. It does get imported if I use a config: instead of typed_config:. Documentation from Envoy suggests it should work. I see typed_config used in other filters when I list out the listener.

Even a workaround that doesn’t use an EnvoyFilter would be cool at this point.