Need support for http/2 CONNECT upgrade

[giri-varma]

Setup: We have a dual envoy proxy setup. A front envoy (v1.12.2) configured by a custom XDS for global routing and then the second layer (v1.16.2) configured with Contour as a single cluster ingress controller.

Problem: We are trying to enable web-socket support at both levels. Have been able to successfully enable it directly at the second level (Contour) with the enableWebsockets flag on the HttpProxy resource. But since the connection between the two envoys is http/2, I fear the websocket upgrade is being rejected. From envoy's documentation looks like the second envoy (Contour in this case) needs to allow CONNECT upgrades.

Feature Request: Ability to add CONNECT type in UpgradeConfig and set allow_connect flag in Http2ProtocolOptions . We might need something similar to this change. But please note that the change does not work. So, there could be other settings that I am missing.

Please let me if you need more info.

[youngnick]

I think this feature is reasonable, and we will look at getting it prioritised. Thanks for the issue @giri-vmw. I can't make any promises about timeline yet though.

[giri-varma]

Thanks @youngnick!

If it helps, I have updated my test change above and it seems to be working now. The following two configs are what needs to be updated.

• Enable Http2ProtocolOptions.AllowConnect on the listener's filter chain
• Also, add CONNECT under UpgradeConfig.UpgradeType to the routes with websocket enabled

I understand that we still need to surface this to the HttpProxy resource. Looking forward to the update :)

[youngnick]

Thanks @giri-vmw! So, just to confirm, this should only be enabled if there are websocket-enabled routes that point to gRPC services that use h2, not h2c?

[giri-varma]

That's a good question, which I don't think I can answer. For our use case itself, we need only h2. But others might need h2c, since http2 CONNECT is by itself a separate feature. I think this might need to be exposed as a separate flag from enableWebSockets for http2 upgrades other than a websocket.

To clarify a bit, the upstream service itself is configured to use http/1.1. The connection between the two envoys is using http2. The front envoy accepts http/1.1 connection from the client (browser) and tunnels the websocket connection as an http2 connection. The second envoy translates the http2 back to http/1.1 based on the :protocol field in the http2 CONNECT request. Ref.: https://www.envoyproxy.io/docs/envoy/v1.16.2/intro/arch_overview/http/upgrades.html?highlight=websocket#websocket-over-http-2-hops.

[youngnick]

Hmm, it seems like maybe we should;

• enable Http2ProtocolOptions.AllowConnect on the filter chain by default
• add CONNECT under UpgradeConfig.UpgradeType only on routes that request websockets be enabled.

I need to read up a bit more on if there are any implications about allowing the upgrade at the listener level and then not configuring it, but that seems like it might work. Thoughts @giri-vmw ?

[giri-varma]

Yep, that sounds like it should work for our use case. Also, we have recently updated to v1.12 of Contour, so the fix need not be a patch in 1.10 (the above referenced change was intended as a patch for 1.10).

[giri-varma]

@youngnick any updates on the issue?

We have been using a custom image with the temporary fix. Looks like Contour has new security fixes and we would like to pull them in with the AllowConnect fix if possible.

[youngnick]

Hi @giri-varma, sorry, no further updates at the moment. I'll ping @xaleeks and make sure this is on his radar, so we can get it prioritised and in sometime. I think the only outstanding thing here is to have someone check the spec for CONNECT and see if there's any implications of setting the Allow in the absence of the UpgradeConfig.UpgradeType directive.

[giri-varma]

Sounds good, thanks! I can try to look up on that a bit. But I fear I am not an expert to fully understand the security implications of it.

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[peterbosalliandercom]

Any news on this? @youngnick

[peterbosalliandercom]

Nobody migrating to http2?