Bad request returns forbidden

[ChezCrawford]

When using the opa-envoy-plugin, requests such as sending invalid JSON result in a "403 - Forbidden" being returned to the downstream.

Example:

curl -i -X POST \ 
   -H "Content-Type: application/json" \
   --data '{"this-is-not-json"' \
  http://$ENVOY_URL/api/some-resource

Returns:

HTTP/1.1 403 Forbidden
date: Mon, 06 Dec 2021 15:44:38 GMT
server: envoy
content-length: 0

The error in the case above occurs when the plugin is attempting to fetch the parsed body here.

We think we could potentially submit a PR to the plugin that provides an enhancement to return a service.auth.v3.DeniedHttpResponse with a "400 - Bad Request" response but wanted to see what the community's thoughts were on something like this before we did so.

Would this type of enhancement make sense? Are there other possible solutions here that we may have overlooked?

Other data:

• OPA version: v0.35.0-envoy-1

Logs:

envoy_1  | [2021-12-06 14:37:55.828][25][debug][filter] [source/extensions/filters/http/ext_authz/ext_authz.cc:128] [C7][S2463566773360943761] ext_authz filter finished buffering the request since stream is ended
opa_1    | {"decision_id":"52b5f686-15a6-4dee-9b42-00a268d15f38","error":{"message":"unexpected EOF"},"input":null,"labels":{"id":"6c6eed8e-18ff-48d6-bbd0-90a8a0676d40","version":"0.29.4-envoy-7"},"level":"info","metrics":{"timer_server_handler_ns":180000},"msg":"Decision Log","path":"envoy/authz/allow","requested_by":"","time":"2021-12-06T14:37:55Z","timestamp":"2021-12-06T14:37:55.829998641Z","type":"openpolicyagent.org/decision_logs"}
envoy_1  | [2021-12-06 14:37:55.830][25][debug][grpc] [source/common/grpc/google_async_client_impl.cc:360] Finish with grpc-status code 2
envoy_1  | [2021-12-06 14:37:55.830][25][debug][grpc] [source/common/grpc/google_async_client_impl.cc:212] notifyRemoteClose 2 unexpected EOF
envoy_1  | [2021-12-06 14:37:55.831][25][debug][http] [source/common/http/filter_manager.cc:883] [C7][S2463566773360943761] Sending local reply with details ext_authz_error
envoy_1  | [2021-12-06 14:37:55.831][25][debug][http] [source/common/http/conn_manager_impl.cc:1469] [C7][S2463566773360943761] encoding headers via codec (end_stream=true):
envoy_1  | ':status', '403'
envoy_1  | 'date', 'Mon, 06 Dec 2021 14:37:55 GMT'
envoy_1  | 'server', 'envoy'
envoy_1  |

[srenatus]

Can this be achieved with the status_on_error setting described here? 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

[ChezCrawford]

Can this be achieved with the status_on_error setting described here? 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

We've thought about that but the concern there is that setting covers a wide range of errors including network errors.

When considering the patch, we were thinking of specifically handling errors that occur in envoyauth.RequestToInput as "Bad Request"...

[srenatus]

Gotcha. Yeah I think that makes sense. If you'd pick that up, it'll be great.

Can you imagine cases where the current behaviour is desirable? I'm wondering about backwards compatibility...

[ChezCrawford]

Off the top of my head I was not sure if there are situations where the current behavior is desirable. However, we could make this behavior opt-in via configuration if we wanted to be safe...

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.