More guidance on authservice match criteria

[dippynark]

I am using the Match criteria so that I can use a single authservice Deployment to authenticate multiple services and hopefully (am yet to test) share state so that you only have to log in once to access multiple services.

I tried using the host header, which I couldn't get to work, but based on this comment I added a header to my authenticated service using a VirtualService

      headers:
        request:
          add:
            x-authservice-match: kiali

which I could then match on in my authservice config

         "match": {
            "header": "x-authservice-match",
            "equality": "kiali"
          },

This feels like a hack - is this expected usage or are there other headers that would be more appropriate?

Additionally the match only works for me if it was all lowercase, for example using X-Authservice-Match for both the VirtualService and the config fails to match, although my understanding of HTTP headers is that they should be case insensitive.

I am using the latest authservice image: v0.3.1

[alemonmk]

Hi, I've been looking around for few hours trying to find out how to use host header, and try something like your workaround in Contour but no avail, and turns out it's not host, but :authority!

From this Medium post, section "Send Custom Headers to ext_authz server", it showed us what the headers Envoy sends looks like. Actually I was searching about "Context Extensions" in desperate attempt when I encountered this post.

I don't see :authority documented anywhere, without insight like this it is impossible to make things work. /headbang /facepalm

[dippynark]

Envoy's internal HTTP representation is based on HTTP/2 which uses :authority as the HTTP/1.x Host header: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-field-config-route-v3-routeaction-cluster-header

Additionally, in the Bookinfo example at least, Envoy is configured to call out over HTTP/2: https://github.com/istio-ecosystem/authservice/blob/master/bookinfo-example/config/productpage-external-authz-envoyfilter-sidecar.yaml#L50

In the end I achieved what I was trying to achieve with authservice using oauth2-proxy, which I have written up here: https://www.jetstack.io/blog/istio-oidc/

[dippynark]

To answer my own issue, HTTP/2 mandates that header field names are lowercase (compared to HTTP/1.x headers field names which are just case-insensitive). From https://tools.ietf.org/html/rfc7540:

Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. A request or response containing uppercase header field names MUST be treated as malformed

[dippynark]

Also relevant: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/header_casing

[phllpmcphrsn]

I know this is old, but I'm looking to do what you stated in the issue statement. I've looked over your guide before and see that you went with oauth2-proxy, instead. Does that mean there wasn't a less "hacky" way discovered for authservice?