Expose option to remove headers in the transformation filter

[ably77]

Version

1.11.x (latest stable)

Is your feature request related to a problem? Please describe.

We are attempting to scrub headers from requests that require extauth. These particular headers need to be scrubbed before extauth and not after. We have tried headerManipulation but that seems to scrub headers after extauth. We have worked around this by using a transformation template to convert the values of these headers as empty strings (see below)

stagedTransformations:
  early:
    requestTransforms:
      - requestTransformation:
          transformationTemplate:
            headers:
              x-header1:
                text:
              x-header2:
                text:
              x-header3:
                text:
            passthrough: {}
extauth:
  customAuth: {}

Use case for scrubbing these particular headers before customAuth is so that clients cannot pass them in themselves and fake an authenticated request

Describe the solution you'd like

A more ideal solution would be to expose the option headersToRemove in the transformation filter, and set this in the early stage before extauth

Describe alternatives you've considered

see above example for current workaround to scrub values with transformationTemplate

Additional Context

No response

[kdorosh]

@ably77 where do the headers that need to be scrubbed come from in normal flows? I imagine the ideal solution is something that passes this metadata more internal to envoy (rather than request header). for example metadata_context_namespaces or typed_metadata_context_namespaces, from https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_authz/v3/ext_authz.proto#envoy-v3-api-msg-extensions-filters-http-ext-authz-v3-extauthz

additionally, why are we using an entirely custom extauth server rather than ours with passthrough auth? our server also has similar functionality built into its api we could lean on

[kdorosh]

we do this in our extauth server today using https://docs.solo.io/gloo-edge/master/reference/api/github.com/solo-io/gloo/projects/gloo/api/external/envoy/extensions/extauth/sanitize.proto.sk/

[kdorosh]

the above configuration is not available to users, we should either add sanitize header to open source or move header manipulation earlier in the filter chain @ashishb-solo this request makes sense now we can pursue it

[ashishb-90]

A few questions here:

1. @ably77 Based on my testing, client-provided headers are not passed to extauth by default. There are some configuration options that allow this however:

   spec:         
     extauth:             
       httpService:              
         request:              
           allowedHeaders:        
           - "x-my-custom-header"
           allowedHeadersRegex:           
           - "x-my-customregex-.*"   
   

   Could the users' requests here be satisfied by simply updating these rules to be a bit more strict?

2. @kdorosh I'm rather nervous about moving the header manipulation plugin earlier in the filter chain; is there a possibility that this could be an incompatible change to users who already use this plugin?

Based on my trepidations in the previous question, I feel that the best way to go about this is to expose the sanitize extension that envoy provides. @kdorosh, I'd like to know how you feel about this.

Thanks!

[kdorosh]

@ably77 explained the request as ensuring that the header the upstream receives is one that can be trusted. So if extauth doesn't receive the header, then we just need to ensure that if we copy the header out of the extauth response and send it to final destination upstream that it would overwrite (not add to) any existing headers.

since header manipulation does not configure a filter (see https://github.com/solo-io/gloo/blob/b8baa7a6ff95a7d296132c20c5e9bd65cb1f89eb/projects/gloo/pkg/plugins/headers/plugin.go#L81-L84) rather than leaning on pre-existing envoy api (see https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route.proto) we cannot move it earlier if that's required (which I don't think it is anymore, given your extauth testing). Instead we'd have to use our sanitize header filter in that scenario

[ashishb-90]

Okay, after some offline discussions, we'd like to confirm what the desired behaviour is for this:

1. if extauth rejects the request, the header should be deleted from requests to the upstream

2. if extauth accepts the request, then the request forwarded to the upstream should

   2.1 have the header value be set to the value provided by extauth, AND

   2.2 all other references to the header should be scrubbed from the request

Can we confirm these details to make sure we are on the right track before we continue forward?

[kdorosh]

@ably77 we think this is already possible today if the user adds headers_to_remove to the grpc ok response in their server (or the magic x-envoy-auth-headers-to-remove header if an http extauth service), see https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto#service-auth-v3-okhttpresponse

note the user may also want to set clearRouteCache to true since removing headers can affect routing