Skip to content
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

Closed

Conversation

agrawroh
Copy link
Contributor

@agrawroh agrawroh commented Jan 10, 2023

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 in ext_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 to false 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

@repokitteh-read-only
Copy link

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #24845 was opened by agrawroh.

see: more, trace.

@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @lizan
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #24845 was opened by agrawroh.

see: more, trace.

@agrawroh agrawroh force-pushed the extauthz-error-allow-headers branch 2 times, most recently from 7e6168e to f5fc138 Compare January 10, 2023 07:21
@agrawroh
Copy link
Contributor Author

/retest

@wbpcode
Copy link
Member

wbpcode commented Jan 10, 2023

cc @mattklein123 for API change and quick review to this design.

@wbpcode wbpcode assigned mattklein123 and wbpcode and unassigned lizan Jan 10, 2023
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
@agrawroh agrawroh marked this pull request as ready for review January 11, 2023 19:20
Copy link
Member

@mattklein123 mattklein123 left a 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;
Copy link
Member

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?

Copy link
Contributor

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?

Copy link
Member

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.

Copy link
Contributor Author

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>
changelogs/current.yaml Outdated Show resolved Hide resolved
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
@agrawroh agrawroh requested review from mattklein123 and wbpcode and removed request for ggreenway, mattklein123 and wbpcode January 17, 2023 06:53
Copy link
Member

@mattklein123 mattklein123 left a 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()
Copy link
Member

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:
Copy link
Member

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?

Comment on lines +64 to +66
propagate_response_on_failure_(config.has_http_service()
? config.http_service().propagate_response_on_failure()
: false),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment

Comment on lines +182 to +183
// 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.
Copy link
Member

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()) {
Copy link
Member

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?

@lizan
Copy link
Member

lizan commented Jan 20, 2023

/retest

@repokitteh-read-only
Copy link

Retrying Azure Pipelines:
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #24845 (comment) was created by @lizan.

see: more, trace.

@github-actions
Copy link

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!

@github-actions github-actions bot added the stale stalebot believes this issue/PR has not been touched recently label Feb 19, 2023
@github-actions
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api stale stalebot believes this issue/PR has not been touched recently waiting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants