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

Feature support connection info in route matching #8453

Conversation

jimini-lumox
Copy link
Contributor

Description: Add the ability to route match based on client credentials.

This is an output of the changes requested for PR #8248 (#8248 (comment))
To more cleanly support #8248 , it would be better to be able to route based on downstream connection details, instead of hoisting more information into headers.

As an API example, route matching based on presented and/or expired client certificate is supported.
The end goal for #8248 is to route based on 'validated'.

By default the routing rules are unchanged.

Risk Level: Medium
Testing: Currently Manual tests
Docs Changes: API proto changes
Release Notes: N/A

Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.

🐱

Caused by: #8453 was opened by jimini-lumox.

see: more, trace.

Signed-off-by: Michael Hargreaves <[email protected]>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

Some API comments to start things. Also, have you considered having a filter put this information in dynamic metadata and doing a more generic match on that in the route table? I'm not generally a fan of putting too much business logic for specific cases here unless it's widely interesting.

CC @PiotrSikora

api/envoy/api/v2/route/route.proto Show resolved Hide resolved
api/envoy/api/v2/route/route.proto Outdated Show resolved Hide resolved
api/envoy/api/v2/route/route.proto Show resolved Hide resolved
@lizan
Copy link
Member

lizan commented Oct 5, 2019

Some API comments to start things. Also, have you considered having a filter put this information in dynamic metadata and doing a more generic match on that in the route table? I'm not generally a fan of putting too much business logic for specific cases here unless it's widely interesting.

@htuch My thought on this is consolidating with what RBAC has, we already have huge overlap with there and the properties from the TLS connection will be also interested there. This falls into the goal of consolidating all HttpMatcher in v4.

@htuch
Copy link
Member

htuch commented Oct 7, 2019

@lizan yeah, RBAC unification makes sense. Is there an issue and/or roadmap somewhere to provide a north star? Is there anything actionable in this review on that front?

Comment on lines 370 to 373
if (criteria.presented()) {
const bool peerPresented = stream_info.downstreamSslConnection() &&
stream_info.downstreamSslConnection()->expirationPeerCertificate();
matches &= *criteria.presented() == peerPresented;
Copy link
Contributor

Choose a reason for hiding this comment

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

nits: I think has_value() and value() is preferred if it is optional<bool>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

modified to use has_value() & value()

@lizan
Copy link
Member

lizan commented Oct 8, 2019

@lizan yeah, RBAC unification makes sense. Is there an issue and/or roadmap somewhere to provide a north star? Is there anything actionable in this review on that front?

Part of #5569, this is the one of big item we've been discussing for v4 and UDPA.

Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

Great, starting to review implementation, a few comments.
/wait

api/envoy/api/v2/route/route.proto Show resolved Hide resolved
source/common/router/BUILD Outdated Show resolved Hide resolved
source/common/router/config_impl.cc Outdated Show resolved Hide resolved
source/common/router/config_impl.cc Outdated Show resolved Hide resolved
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

Thanks, looks mostly good, but some comments to be resolved.
/wait

include/envoy/router/router.h Outdated Show resolved Hide resolved
test/common/router/route_fuzz_test.cc Show resolved Hide resolved
@@ -502,6 +502,16 @@ class MetadataMatchCriteria {
mergeMatchCriteria(const ProtobufWkt::Struct& metadata_matches) const PURE;
};

class TlsContextMatchCriteria;
using TlsContextMatchCriteriaConstPtr = std::unique_ptr<const TlsContextMatchCriteria>;
Copy link
Member

Choose a reason for hiding this comment

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

Nit: move this after the class definition below, no need to forward declare for this simple class.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

removed

Copy link
Member

Choose a reason for hiding this comment

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

I still see the forward declaration above..

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, thought it was referring to same comment as tls_context_match_criteria_impl.h below
Fixed now.

source/common/router/tls_context_match_criteria_impl.cc Outdated Show resolved Hide resolved
source/common/router/tls_context_match_criteria_impl.h Outdated Show resolved Hide resolved
@@ -53,7 +53,9 @@ class TestConfigImpl : public ConfigImpl {
bool validate_clusters_default)
: ConfigImpl(config, factory_context, validate_clusters_default), config_(config) {}

RouteConstSharedPtr route(const Http::HeaderMap& headers, uint64_t random_value) const override {
RouteConstSharedPtr route(const Http::HeaderMap& headers,
Copy link
Member

Choose a reason for hiding this comment

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

I'm probably missing it, but could you point me to where the tests for the new behaviors are?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've just now pushed the unit-test for tls-context matching.

Signed-off-by: Michael Hargreaves <[email protected]>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

LGTM modulo the two remaining small nits.

@@ -5780,6 +5787,95 @@ name: foo
}
}

TEST_F(RouteMatcherTest, TlsContextMatching) {
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 a brief comment above this test explaining what it does.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've added a comment - let me know if it needs more details. thanks

@htuch htuch added waiting and removed api labels Oct 17, 2019
Signed-off-by: Michael Hargreaves <[email protected]>
Signed-off-by: Michael Hargreaves <[email protected]>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

Thanks, this is great!

@htuch htuch merged commit 350e4ce into envoyproxy:master Oct 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants