Adopt Envoy matcher API for HTTP filters

lahabana commented 2 years ago

Description

For Gateway use cases, it's generally expected that virtual hosts (however we define that) can be configured independently. That is, if I configure fault injection for "foo.example.com", I don't want to also get fault injection on "bar.example.com", even though these hostnames are being served by the same proxy.

In Envoy configuration this is tricky.

Envoy has 2 layers of filters:

There is a listener filter chain (roughly) per port
There is a HTTP filter chain per HTTP connection manager When we do HTTP processing on Envoy, the HTTP connection manager is the last filter in the listener filter chain. The HTTP connection manager contains a list of hostnames to accept, and a single HTTP filter chain.

This means that for each HTTP connection manager there is only one filter chain. This is a problem because we really want there to be a filter chain per virtual host so that we can present a configuration model where features can be enabled at virtual host scope.

Without writing custom extensions, there are 2 ways that I know of to achieve this in Envoy.

The first way is to require HTTPS at all times. The TLS listener filter matches the SNI name presented by the client and wraps a HTTP connection manager configuration. This lets you have a separate HTTP connection manager for each virtual host, which is exactly what we would prefer.
The second way is to use the alpha matching API. In this approach, we wrap a protobuf matcher configuration around each filter that we configure on the HTTP connection manager. This gives us a bit less flexibility overall (since the HTTP connection manager is still shared across virtual hosts), but we can emulate independent filter chains.

The filter chain matching approach has the advantage that we can make it work the same for HTTP and HTTPS.

The filter chain matching approach has the disadvantage of needing to make linear filter matches (the length filter chain is a multiple of the number of virtual hosts). It also needs us to upgrade the go-control-plane version, since we can't actually express the kind of match we need with the protobufs at the current version.

lahabana commented 2 years ago

Draft PR: https://github.com/kumahq/kuma/pull/2721

jpeach commented 2 years ago

triage: Will get back to this when we need to provide different filters for the same HTTPConnectionManager.

github-actions[bot] commented 2 years ago

This issue was inactive for 30 days it will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant please comment on it promptly or attend the next triage meeting.

github-actions[bot] commented 2 years ago

This issue was inactive for 30 days it will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant please comment on it promptly or attend the next triage meeting.

github-actions[bot] commented 1 year ago