Envoy: ext_authz: Is it possible to add custom headers to HTTP authorization server requests?

[jeffpang]

Title: ext_authz: Is it possible to add custom HTTP headers to authorization server requests?

Description:
I'm trying to add a route dependent header to the requests sent to an ext_authz HTTP authorization server. I tried using request_headers_to_add on the route, route_action, and the virtual_host, but those only appear to be added when the request is forwarded to the upstream cluster and not the authorization server. Example:

"routes": [
  {
    "match": {
      "prefix": "/path1"
    },
    "route": {
      "cluster": "cluster1",
      "request_headers_to_add": [
        {
          "header": {
            "key": "x-auth-header",
            "value": "value1"
          }
        }
      ]
    }
  },
  {
    "match": {
      "prefix": "/path2"
    },
    "route": {
      "cluster": "cluster2",
      "request_headers_to_add": [
        {
          "header": {
            "key": "x-auth-header",
            "value": "value2"
          }
        }
      ]
    }
  }
]

Is there any way to add custom headers to requests on a per-route basis before sending them to the HTTP authorization server (or include metadata in some other way)?

[dio]

@jeffpang there is an active PR related to this: https://github.com/envoyproxy/envoy/pull/3888/files

See if this proposed change to the ext_authz's config matches your requirement: https://github.com/gsagula/envoy/blob/b4e043da83de99dea0983af1034623637b571a96/api/envoy/config/filter/http/ext_authz/v2alpha/ext_authz.proto#L66-L70

cc. @gsagula

[jeffpang]

Thanks @dio. I actually tried pulling in that PR into my envoy image already since I've been following it. :)

I'm not sure if the issue is with the ext_authz filter itself since I can get all downstream headers included in the authorization request. But I can't figure out how I can add a header in envoy and have my added header included in the request. As far as I can tell this is because the request_headers_to_add are added after the filters are processed and not before.

[gsagula]

Thanks @dio

@jeffpang The current implementation sends all the headers in the client request to the authorization server, request_headers_to_add won't be sent over. https://github.com/envoyproxy/envoy/pull/3888 won't help you either since it only implements two whitelists to restrict headers sent to the authorization server and header from the authorization server to the upstream services.

[jeffpang]

Thanks @gsagula; that is helpful to know. Two followup questions:

1) Is this choice by design? Would it be a coherent feature request? The use case I am contemplating is to include metadata about Envoy's route configuration in the authorization request so I can differentiate different types of requests. For example, different routes require different types of authorization and I was hoping to include that metadata in the Envoy config and propagate it to the authorization service. I can do this in the authorization service as well, but I thought it would be better to have a single configuration source, and so the authorization service doesn't have to repeat the route matching that Envoy does already.

2) Do you know if the gRPC auth service can receive per-route metadata in authorization checks? The
attributes in the CheckRequest message have a context_extentions field, but I wasn't sure how that was populated.

[gsagula]

Hi @jeffpang, sorry for the delay here.

1. This choice was by design. The current HTTP implementation was introduced to support Ambassador's authorization flow. Can't you use Path to identify the route? If not, could you please provide a more concrete example of your use-case?

2. I quick looked at check_request_utils, but I'm not sure where/how context_extentions gets populated. Either HTTP or gRPC uses the same check request mechanism.

cc @saumoh

[jeffpang]

Thanks @gsagula. That makes sense; I was just curious. I can definitely use the Path in the authorization server to identify the route; I was just hoping to avoid having to define all the routes in both Envoy and in the authorization server (to avoid a split brain scenario where Envoy is has one set of routes but the authorization server has a different set of routes).

I actually figured out a workaround that fits my use case, so we can close this ticket. The workaround is to add a local listener in Envoy and have the ext_authz filter use that local listener as the authorization server. The local listener can add/remove headers as desired before proxying the request to the actual authorization server.

[dio]

@jeffpang that’s a very creative workaround 🙂.
I’m closing this issue. But feel free to reopen or create another issue if there’s a need for follow up. Thanks.

[auFrankOh]

@jeffpang Could you elaborate regarding your "workaround"? I'm trying to do similar as you stated before: wanting to configure headers based on incoming HTTP before I send to ext auth server. Did you create a service that handles modification and mapping in between your ext_authz filter and actual ext authz server?