Support for custom error code when extAuth fails

[luvk1412]

Description:

Envoy proxy supports status_on_error field in extAuth filter, but in eg's extauth, the support is not there. I would like this to be supported.

Use case

We already have Availability and SLA pipelines built which account for 5xx as not available and 4xx as available. Due to default setting of ext auth filter where it responds with 403 when ext auth server is not reachable, this breaks our assumption. Also we feel when ext auth server is down or has some bug due to which it responds with 5xx, clients should get 5xx and not 403 as its an error on backend side and user is not forbidden to use the service otherwise suggested by current default behaviour.

[arkodg]

hey @luvk1412 can you use responseOverride for this case ?
https://gateway.envoyproxy.io/docs/tasks/traffic/response-override/
the statusCode field is only available in v1.3.0 https://gateway.envoyproxy.io/docs/api/extension_types/#customresponse

[luvk1412]

@arkodg i don't think so.
My understanding is that using responseOverride will lead to override of legitimate 403's from upstream as well. Please correct me if i am understanding something wrong here. This maybe could have been used if CustomResponseMatch had a matcher on body or headers maybe, because for my upstream 403's the content-length is non zero and i think the default 403 thrown by envoy proxy due to extAuth unavailability has content-length as 0, so i would have been able to differentiate between the 2.

[arkodg]

good point, would a match/differentiation of local vs upstream be good enough here ?

[luvk1412]

good point, would a match/differentiation of local vs upstream be good enough here ?

Yes @arkodg this could also work. I am assuming default reply(403) if and when generated by envoy would get auto categorised under local right ?

Also on the other hand adding support for status_on_error field already present in envoy proxy's ext auth filter also seems like an easy solution which is available out of the box for that filter. Any reason particular reason to not consider that approach ?

[arkodg]

yeah hoping we leverage %RESPONSE_CODE_DETAILS% here to decipher how the status code was set, and for ext auth case it shouldnt say via_upstream

im hoping we can solve this in a more generic way, else we'll (project as well as users) need to configure a API field for every feature instead of doing it in one place

[luvk1412]

yeah hoping we leverage %RESPONSE_CODE_DETAILS% here to decipher how the status code was set, and for ext auth case it shouldnt say via_upstream

I tried to go through envoy-v3-api-msg-extensions-filters-http-custom-response-v3-customresponse (I assumed this is what is being used in eg to provide response override). I see that only relevant input for SinglePredicate i could find was HttpResponseHeaderMatchInput. Is this what you are referring to be used for input ? or you are thinking on lines of introducing some changes in Envoy proxy itself to accomplish this ? Not sure what was meant by %RESPONSE_CODE_DETAILS%. After going through docs i assume you must be referring to some sort of predefined input config.

[arkodg]

the local setting in the API could translate into a a invert match in metadata matcher https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/matching/input_matchers/metadata/v3/metadata.proto#extension-envoy-matching-matchers-metadata-matcher and afaik RESPONSE_CODE_DETAILS is a valid metadata
cc @zhaohuabing