Closed dippynark closed 3 years ago
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
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/
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
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?
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 VirtualServicewhich I could then match on in my authservice config
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