0

I am attempting to set up an authn/authz flow using istio and oauth2-proxy. This flow consists of:

  1. An ext_authz EnvoyFilter that targets and app label. I.e., the istio-sidecar on the targeted app's pod will intercept and reroute to an external authozation service.
  2. As ext_authz service I use oauth2-proxy, which forwards the authentication request to an external identity provider, the returns the authorization and sets some x-auth... headers
  3. Finally, an AuthorizationPolicy parses the contents of for example, x-auth-request-email and allows traffic through based on that.

Below are the EnvoyFilter and AuthorizationPolicy

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: "ext-authz-myapp"
spec:
  workloadSelector:
    labels:
      app: "myapp"
  configPatches:
    - applyTo: CLUSTER
      match:
        cluster:
          service: "oauth2-proxy.{{.Env.ARGOCD_ENV_NAMESPACE}}.svc.cluster.local"
      patch:
        operation: MERGE
        value:
          name: "myapp.oauth2-proxy.{{.Env.ARGOCD_ENV_NAMESPACE}}.svc.cluster.local" # see https://github.com/istio/istio/issues/30271
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          portNumber: 5678 # service or pod port?!
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
              subFilter:
                name: envoy.filters.http.router
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.ext_authz
          typedConfig:
            "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
            httpService:
              authorizationRequest:
                allowedHeaders:
                  patterns:
                    - exact: cookie
                    - exact: x-forwarded-access-token
                headersToAdd:
                  - key: X-Auth-Request-Redirect
                    value: "https://%REQ(Host)%%REQ(:PATH)%"
              authorizationResponse:
                allowedUpstreamHeaders:
                  patterns:
                    - exact: authorization
                    - exact: x-auth-request-user
                    - exact: x-auth-request-email
                allowedClientHeaders:
                  patterns:
                    - exact: content-type
                    - exact: set-cookie
              serverUri:
                cluster: "myapp.oauth2-proxy.{{.Env.ARGOCD_ENV_NAMESPACE}}.svc.cluster.local"
                timeout: 15s
                uri: http://oauth2-proxy.{{.Env.ARGOCD_ENV_NAMESPACE}}.svc.cluster.local:80
            statusOnError:
              code: Forbidden
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: myapp
spec:
  action: DENY
  selector:
    matchLabels:
      app: myapp
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/istio-gateway/sa/istio-gateway"]
      when:
        - key: request.headers[x-auth-request-user]
          notValues:
            - "me@my.domain"

I have not managed to get this workflow to work correctly. In particular, the AuthorizationPolicy appears to run before the EnvoyFilter. Is there a way that I can ensure the correct order? Or is there a better way to achieve what I am trying to do here?

Karl
  • 5,573
  • 8
  • 50
  • 73
  • Why not apply the filter to the istio-ingressgateway pod? – Chris Apr 18 '23 at 11:44
  • Would that make a difference? I am also routing other traffic through the ingress-gateway that does not need to be authenticated/authorized like this – Karl Apr 18 '23 at 12:00
  • I just discovered that there is an INSERT_FIRST directive as well (instead of INSERT_BEFORE), which if set will make the filter run before the AuthorizationPolicy. I will leave the question open for a while though. – Karl Apr 18 '23 at 12:31

0 Answers0