Listener FilterChainMatch using connection metadata

[ssripadham]

Commit Message: FilterChainMatch using metadata on the connection.
Co-authored-by: Piumi Abeynayaka

Additional Description:

config.listener.v3.FilterChainMatch¶
specifies the match criteria for selecting a specific filter chain for a listener.

The following order applies:

• Destination port.
• Destination IP address.
• Server name (e.g. SNI for TLS protocol),
• Transport protocol.
• Application protocols (e.g. ALPN for TLS protocol).
• Directly connected source IP address (this will only be different from the source IP address when using a listener filter that overrides the source address, such as the Proxy Protocol listener filter).
• Source type (e.g. any, local or external network).
• Source IP address.
• Source port.

This pull request adds connection metadata to this list before the Destination port is matched.
This is somewhat related to #18856

Risk Level: Low
Testing: Unit Tests have been added to test different scenarios
Docs Changes: Documentation here (https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/listener/v3/listener_components.proto.html?highlight=filterchainmatch) should be enhanced to hilight the new order.
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

[repokitteh-read-only]

Hi @ssripadham, welcome and thank you for your contribution.

We will try to review your Pull Request as quickly as possible.

In the meantime, please take a look at the contribution guidelines if you have not done so already.

🐱

Caused by: #19950 was opened by ssripadham.

see: more, trace.

[repokitteh-read-only]

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

🐱

Caused by: #19950 was opened by ssripadham.

see: more, trace.

[htuch]

Why do we have a new notion of connection metadata? Doesn't the StreamInfo associated with a connection, providing both dynamic metadata and FilterState suffice?
/wait

[ssripadham]

@htuch - First of all, thanks @htuch for reviewing the code. I am not familiar with StreamInfo. Are you referring to https://www.envoyproxy.io/docs/envoy/v1.21.0/configuration/http/http_filters/lua_filter.html?highlight=streaminfo#config-http-filters-lua-stream-info-wrapper ? In any case, we will still need the changes in FilterChainMatch to match based in the dynamic metadata correct?

[ssripadham]

FilterChain matching is bound to the listener (socket) and is based on Network::ConnectionSocket object.
In this PR, we are attaching the metadata to Network::ConnectionSocket.

During filter chain match, this is referenced as below:

FilterChainManagerImpl::findFilterChain(const Network::ConnectionSocket& socket) const {
  const auto& connection_metadata = absl::AsciiStrToLower(socket.connectionInfoProvider().connectionMetadata());
  ...

However, streamInfo is on Connection itself and not on the Socket and is referenced as below connection().streamInfo().setDynamicMetadata()

How do you propose we use streamInfo to do filterChain match?

[htuch]

The caller should have access to this, e..g. in ActiveStreamListenerBase::newConnection. @lambdai does this work?

[ssripadham]

Right, the change in this PR kicks in filterChainManager().findFilterChain(*socket) in the code below. So it will still require the socket to hold the metadata and the findFilterChain to select the filter chain based on the metadata.

void ActiveStreamListenerBase::newConnection(Network::ConnectionSocketPtr&& socket,
                                             std::unique_ptr<StreamInfo::StreamInfo> stream_info) {
  // Find matching filter chain.
  const auto filter_chain = config_->filterChainManager().findFilterChain(*socket);
 ...
}

[kyessenov]

Unified matcher has been merged #20110. We still need a metadata matcher but that would be an extension now.

[ssripadham]

@kyessenov - This is great to hear. Could you please share the design for Unified matcher and how to integrate metadata matcher to unified filter?

[kyessenov]

Here's an overview https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/matching/matching_listener#arch-overview-matching-listener.

[ssripadham]

Hey @kyessenov - we are unable to use the unified matcher as it doesn't support custom matcher we are building for dynamic metadata matching #23503

[ssripadham]

@kyessenov - Is there a way to support dynamic metadata matching in addition to static string matching in Unified matcher?

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy[\w/]*/(v1alpha\d?|v1|v2alpha\d?|v2))|(api/envoy/type/(matcher/)?\w+.proto).

🐱

Caused by: #19950 was synchronize by ssripadham.

see: more, trace.

[rojkov]

/wait
on CI

[github-actions]

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]

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!