-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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: support modifying and removing query string parameters when using a gRPC authorization server #18009
Conversation
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
@@ -60,8 +60,20 @@ message DeniedHttpResponse { | |||
string body = 3; | |||
} | |||
|
|||
// TODO: Should this be in the core API? |
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.
This is an open question. I feel like it could be valuable alongside HeaderValueOption.
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.
Yes, that would be a good location, but I think the remove
semantics are a bit weird. Would it be cleaner to structure this similar to headers, with query_parameters_to_add
, query_parameter_to_remove
?
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 agree with @htuch, though with introducing a new structure the same as HeaderValue
? But with the QueryParameter
(?) as its name. We can do that via what is suggested (adding query_parameters_to_add
, query_parameter_to_remove
) by Harvey.
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.
Will do
Signed-off-by: John Esmet <john.esmet@gmail.com>
const auto path_without_query = | ||
Http::Utility::stripQueryString(request_headers_->Path()->value()); | ||
// TODO: These two lines should probably be abstracted as | ||
// Http::Utility::formatPathAndQueryParams |
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 still need to do this.
for (const auto& [key, value] : response->query_parameters_to_set) { | ||
ENVOY_STREAM_LOG(trace, "'{}={}'", *decoder_callbacks_, key, value); | ||
// TODO(esmet): Sanitize key/value and/or declare the security posture that we trust the | ||
// authorization server. |
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.
Trusting the auth server seems obvious but I still need to circle back to this TODO
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.
File an issue and link it here will be better I think?
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
/assign-from @envoyproxy/first-pass-reviewers |
@envoyproxy/first-pass-reviewers assignee is @jmarantz |
// TODO(esmet): It might make more sense to store query_parameters_to_set as a vector | ||
// instead of a map since we will likely only ever iterate them linearly. |
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 agree with this, should we go ahead with this PR?
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'll work on adding QueryParamsVector for this.
@@ -213,12 +213,13 @@ void Filter::onComplete(Filters::Common::ExtAuthz::ResponsePtr&& response) { | |||
|
|||
switch (response->status) { | |||
case CheckStatus::OK: { | |||
// Any changes to request headers can affect how the request is going to be | |||
// Any changes to request headers or query parameters can affect how the request is going to be |
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 for this. I totally forgot that we have a route matcher to match query params.
envoy/api/envoy/config/route/v3/route_components.proto
Lines 1995 to 1998 in 7d3057f
// [#next-free-field: 7] | |
message QueryParameterMatcher { | |
option (udpa.annotations.versioning).previous_message_type = | |
"envoy.api.v2.route.QueryParameterMatcher"; |
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
Looks like dio is on this; I'lll drop off this one. |
Signed-off-by: John Esmet <john.esmet@gmail.com>
@rojkov thanks! I ended up needing to specify |
Signed-off-by: John Esmet <john.esmet@gmail.com>
/lgtm api |
Signed-off-by: John Esmet <john.esmet@gmail.com>
Needs a main merge. @rojkov can you do a final pass on this please? /wait |
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
Signed-off-by: John Esmet <john.esmet@gmail.com>
Sorry, needs a merge again. /wait |
Signed-off-by: John Esmet <john.esmet@gmail.com>
@rojkov done! |
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! Looks perfect to me.
@htuch could you please reinstate your API approval?
test/common/http/utility_test.cc
Outdated
EXPECT_EQ(Utility::stripQueryString(HeaderString("/?x=1")), "/"); | ||
EXPECT_EQ(Utility::stripQueryString(HeaderString("/foo")), "/foo"); | ||
EXPECT_EQ(Utility::stripQueryString(HeaderString("/foo?")), "/foo"); | ||
EXPECT_EQ(Utility::stripQueryString(HeaderString("/foo?hello=there")), "/foo"); | ||
EXPECT_EQ(Utility::stripQueryString(HeaderString("/foo/?")), "/foo/"); |
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: I know it's too pedantic, but I feel incompleteness without having these two lines added
EXPECT_EQ(Utility::stripQueryString(HeaderString("/?x=1&y=2")), "/");
EXPECT_EQ(Utility::stripQueryString(HeaderString("/foo?hello=there&good=bye")), "/foo");
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.
that's fair - will add them
Signed-off-by: John Esmet <john.esmet@gmail.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.
LGTM!
/lgtm api |
This PR currently only implements query string modifications when using a gRPC authorization server.
Commit Message: ext_authz: support modifying and removing query string parameters when using a gRPC authorization server
Additional Description:
Risk Level: low, new opt-in feature to an extension
Testing: new unit tests
Docs Changes: Proto spec documented
Release Notes: ext_authz: added :ref:
query_parameters_to_set <envoy_v3_api_field_service.auth.v3.CheckResponse.query_parameters_to_set>
and :ref:query_parameters_to_remove <envoy_v3_api_field_service.auth.v3.CheckResponse.query_parameters_to_remove>
for adding and removing query string parameters when using a gRPC authorization server.Platform Specific Features:
Fixes #3266