envoy: ext_authz(http): Envoy turns AuthorizationResponse status 500 into 403 and drops body
Title: ext_authz(http): Envoy turns AuthorizationResponse status 500 into 403 and drops body
Description:
- User makes an HTTP request against Envoy.
- Envoy makes AuthorizationRequest to ext_authz filter’s http server.
- ext_authz server replies with 503 and a body.
- Envoy returns 403 and no body.
Repro steps: This came up as part of a project so it’s easier to include instructions for that project:
# Clone and checkout branch made for reproducing this issue (see last commit)
git clone git@github.com:arrikto/oidc-authservice.git
cd oidc-authservice
git checkout feature-envoy-ext-authz-repo
# Run the E2E test to get a K3d cluster up with everything running.
# The test will fail, but it's expected.
make bin/deps
make e2e
# Port-forward the service locally
export KUBECONFIG=$HOME/.k3d/kubeconfig-e2e-test-cluster.yaml
kubectl port-forward -n istio-system svc/istio-ingressgateway 8080:80
# Make a request and see that it returns a 403
curl -v http://localhost:8080
Config: Here is the config dump taken from port 15000 of the istio ingressgateway proxy: config_dump.log
Logs: access_log.log
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 27 (13 by maintainers)
@imrenagi I think you can take it. Please let me know if you need help. Thanks!
cc. @ggreenway.
Sure @dio . Will take a look and try to update my PR. thanks!
By definition of error, I mean the case where a call to the authorization service is considered “failed” as opposed to “completed, but with an error”.
Today, the ext_authz filter considers “completed, but with a 5xx error” to be “failed” though one could argue that the call succeeded, it just came back with a 5xx denial. This would fit the use case that you are describing.
We could add configuration to allow you to specify what you consider a failure. It could be just network errors, or network errors + 5xx errors, or something else, sort of like the ‘retry-on’ logic I linked above.
The default value for this configuration would be the current behavior, which is network errors and 5xx codes. For your use case, you’d configure it to only consider network errors as “failures” (for which the response code to the client is the preconfigured error response code) and everything else would be considered successful communication to the auth service, such that 2XX means pass through and everything else means deny with the code, headers, and body provided by the auth service.