listener: filter chain unified matchers #18871
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -14,6 +14,7 @@ import "google/protobuf/duration.proto"; | |
| import "google/protobuf/wrappers.proto"; | ||
|
|
||
| import "xds/core/v3/collection_entry.proto"; | ||
| import "xds/type/matcher/v3/matcher.proto"; | ||
|
|
||
| import "envoy/annotations/deprecation.proto"; | ||
| import "udpa/annotations/security.proto"; | ||
|
|
@@ -36,7 +37,7 @@ message ListenerCollection { | |
| repeated xds.core.v3.CollectionEntry entries = 1; | ||
| } | ||
|
|
||
| // [#next-free-field: 33] | ||
| message Listener { | ||
| option (udpa.annotations.versioning).previous_message_type = "envoy.api.v2.Listener"; | ||
|
|
||
|
|
@@ -120,6 +121,66 @@ message Listener { | |
| // :ref:`FAQ entry <faq_how_to_setup_sni>`. | ||
| repeated FilterChain filter_chains = 3; | ||
|
|
||
| // Unified matcher resolving the filter chain name from the network properties. This matcher is used as a replacement | ||
| // for the per-filter chain match condition | ||
| // `filter_chain_match <envoy_v3_api_msg_config.listener.v3.FilterChain.filter_chain_match>`. | ||
| // If specified, all :ref:`filter_chains <envoy_v3_api_field_config.listener.v3.Listener.filter_chains>` must | ||
| // have non-empty and unique :ref:`name <envoy_v3_api_field_config.listener.v3.FilterChain.name>` fields and omit | ||
| // `filter_chain_match <envoy_v3_api_msg_config.listener.v3.FilterChain.filter_chain_match>` field. | ||
| // | ||
| // Example 1: The following matcher selects three filter chains as follows: | ||
| // | ||
| // * if the destination port is 80, then the filter chain "http" is selected; | ||
| // * if the destination port is 443 and the source IP is in the range 192.0.0.0/2, then the filter chain "internal" is selected; | ||
| // * otherwise, if the destination port is 443, then the filter chain "https" is selected; | ||
| // * otherwise, the default filter chain is selected (or the connection is rejected without the default filter chain). | ||
| // | ||
| // .. code-block:: yaml | ||
|
There was a problem hiding this comment. Can we make this stanza use the actual config checking/validation version so it doesn't get out of date? There was a problem hiding this comment. Ack, pending relevant protos merged. |
||
| // | ||
| // filter_chain_matcher: | ||
| // matcher_tree: | ||
| // input: | ||
| // typed_config: | ||
| // "@type": type.googleapis.com/envoy.extensions.matching.common_inputs.network.v3.DestinationPortInput | ||
| // exact_match_map: | ||
| // map: | ||
| // "80": | ||
| // action: | ||
| // name: http | ||
| // "443": | ||
| // matcher: | ||
| // matcher_tree: | ||
| // input: | ||
| // typed_config: | ||
| // "@type": type.googleapis.com/envoy.extensions.matching.common_inputs.network.v3.SourceIPInput | ||
| // custom_match: | ||
|
There was a problem hiding this comment. Even though it's probably discussed in the documentation for the SNI custom matcher, can you clarify below the match semantics for different server names? I assume it would be implemented as some type of trie with most specific matches? There was a problem hiding this comment. Yes, it might be better to have a look at the network inputs and trie matcher PRs. The inputs should generally be constant in the input, and matching should be sublinear with IP and domain names. Port ranges should use segment trees for logarithmic performance. ALPN lists are tricky to handle, which needs some core matcher framework support to improve. |
||
| // typed_config: | ||
| // "@type": type.googleapis.com/xds.type.matcher.v3.IPMatcher | ||
| // range_matchers: | ||
| // - ranges: | ||
| // - address_prefix: 192.0.0.0 | ||
| // prefix_len: 2 | ||
| // on_match: | ||
| // action: | ||
| // name: internal | ||
| // - ranges: | ||
| // - address_prefix: 0.0.0.0 | ||
| // on_match: | ||
| // action: | ||
| // name: https | ||
| // | ||
| // | ||
| // .. note:: | ||
| // | ||
| // Once matched, each connection is permanently bound to its filter chain. | ||
| // If the matcher changes but the filter chain remains the same, the | ||
| // connections bound to the filter chain are not drained. If, however, the | ||
| // filter chain is removed or structurally modified, then the drain for its | ||
| // connections is initiated. | ||
| // | ||
| // [#not-implemented-hide:] | ||
|
There was a problem hiding this comment. I see this configuration as being one of the ones that will be very difficult for users to actually piece together without examples. Can we make sure that somehow we wire up the extension docs system here so that this somehow lists out all supported match inputs and relevant typed configs, etc.? We need to guide users much more specifically on how to use this new field. There was a problem hiding this comment. Agree, we need more examples. I can add some but I'd really need #19493 merged first for protos to become available. There is an issue with cncf/xds protos not being documented. |
||
| repeated xds.type.matcher.v3.Matcher filter_chain_matcher = 32; | ||
|
|
||
| // If a connection is redirected using *iptables*, the port on which the proxy | ||
| // receives it might be different from the original destination address. When this flag is set to | ||
| // true, the listener hands off redirected connections to the listener associated with the | ||
|
|
||
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 doesn't need to block the PR, but if we wanted to really prove out how usable the API is, I think we could do it without implementing it in Envoy. Snow has a golang implementation of the generic matcher. Istio already has an extensive test suite for filter chain matching, based on a golang implementation of the current FCM logic. So if we were able to implement the new matcher in Istio (which presumably we need to do anyways after this merges), we could get full test coverage as well before committing to the Envoy implementation.
All of that may be harder than just doing the implementation though, just throwing out the idea.
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.
Generic matcher does not have custom match implemented in either envoy or golang, so it's not really realistic at this stage.
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 was referring to envoyproxy/go-control-plane#511. I guess would need to add all the custom matchers though