-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ext_authz: allow headers propagation when allow_debugging_failures is set #24845
Conversation
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
7e6168e
to
f5fc138
Compare
/retest |
cc @mattklein123 for API change and quick review to this design. |
f5fc138
to
6021b8d
Compare
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
6021b8d
to
6ccd206
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
High level question/comment to get started. Thank you!
/wait
// | ||
// 2. When set to false, the filter would return a 403 or `status_on_error` (if set) and would | ||
// not propagate any response body or headers back to the client. This is the default behavior. | ||
bool allow_debugging_failures = 18; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would name this propagate_response_on_failure
?
Also, is this feature HTTP specific as it seems to pivot on 5xx? Should this actually be part of the HttpService object vs. global?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about adding a field analogous to allowed_headers
for allowed_response_headers
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, is this feature HTTP specific as it seems to pivot on 5xx? Should this actually be part of the HttpService object vs. global?
Sounds reasonable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @mattklein123. That sounds reasonable to me as well.
@ggreenway Sorry, I'm not able to understand the intention behind adding allowed_response_header
. Is the idea to limit what could be propagated back to the client when there are failures? We expose two lists allowed_client_headers
and allowed_upstream_headers
today which serves similar purpose.
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this is on the right track. A few comments, thanks.
/wait
@@ -114,6 +114,9 @@ ClientConfig::ClientConfig(const envoy::extensions::filters::http::ext_authz::v3 | |||
config.http_service().authorization_response().allowed_upstream_headers())), | |||
upstream_header_to_append_matchers_(toUpstreamMatchers( | |||
config.http_service().authorization_response().allowed_upstream_headers_to_append())), | |||
propagate_response_on_failure_(config.has_http_service() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Since the default is false you don't need the has check. You can just directly get the value from the default http_service() object.
@@ -250,6 +250,16 @@ message HttpService { | |||
|
|||
// Settings used for controlling authorization response metadata. | |||
AuthorizationResponse authorization_response = 8; | |||
|
|||
// This changes the filter's behaviour on errors: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code appears to only do this for 5xx. Can you clarify this? Is there any reason not to do this for 4xx also? This seems generally useful as well?
propagate_response_on_failure_(config.has_http_service() | ||
? config.http_service().propagate_response_on_failure() | ||
: false), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment
// Verify that when a call to authorization server returns a 5xx and `propagate_response_on_failure` | ||
// is set then we preserve the original status code, headers, etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add an integration test for this.
decoder_callbacks_->sendLocalReply( | ||
config_->statusOnError(), EMPTY_STRING, nullptr, absl::nullopt, | ||
Filters::Common::ExtAuthz::ResponseCodeDetails::get().AuthzError); | ||
if (config_->propagateResponseOnFailure()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems odd to me that this logic is split across multiple files and that there is additional logic here for things like stats. Why do we additionally increment stats here? Also, if the header processing is done in the other file can't this file just stay a unified path?
/retest |
Retrying Azure Pipelines: |
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Background
Currently, the
ext_authz
filter [Link] doesn't propagate the headers sent from the upstream service back to the client in case of errors. These errors could be useful for debugging purposes. (See #14001)Changes
This PR adds a new boolean field called
allow_debugging_failures
inext_authz
filter which could be used to control whether or not to propagate the response headers received from the upstream service in case of 5XX errors. It's defaulted tofalse
to maintain the current behavior.Commit Message: Allow upstream headers propagation when
allow_debugging_failures
is set for ext_authz filter.Additional Description: Adds a boolean field in ext_authz filter to control whether or not the response headers received from upstream should be propagated back to the client in case of errors.
Risk Level: Low
Testing: Unit Tests
Docs Changes: Added description of this new field in the docs.
Release Notes: Added
Platform Specific Features: N/A
Signed-off-by: Rohit Agrawal rohit.agrawal@databricks.com