TCP Layer 4 Routing

[JasonMorgan]

I'd like the ability to forward a particular port to a particular service without needing HTTPS. An example being, I run a CI tool called concourse and it gives me the ability to launch ssh sessions to ci jobs. In order to broker the ssh session the cli tool opens a connection to the concourse web app over port 2222. Using an NGINX ingress I accomplish this by creating a config map that instructs the ingress controller to forward everything it gets on 2222 to my concourse web service, tcp: {2222: "tools/ci-concourse-web:2222"}. As of right now this doesn't seem possible with Contour.

[stevesloka]

I see this as a new CRD, something like TCPProxy where you can define the L4 bits, IP Address, ports, etc. I think the starting bits can be limited and just document that (i.e. we're not going to deal with IP address management, etc), but overall I think this can be helpful for the community while still be limited compared to other projects that are full "L4" style proxies.

We just discussed this a bit in #2809 (#2809 (comment)) as well.

[youngnick]

The problem with defining things like IP address is that it requires the Envoy deployment to either have that IP address present on the Linux host, or have certain Linux features enabled so that it can add any address, even if it's not routable.

One of the reasons I've been reluctant to just go ahead with this is that there is a long list of things that you have to achieve with your Envoy deployment before you can request an arbitrary IP address and port (which I see as fundamental for this sort of load balancing). Contour has no way to determine how Envoy will react to sending configs that involve L4 details like IP address without just sending it, and if the config is rejected, Envoy will stop receiving updates from Contour until restarted (this is #1176).

I think that the approach nginx seems to take (you can forward any port on whatever IP address(es) Envoy is listening on) is probably more achievable, but will require a new CRD, as you say.

[stevesloka]

Yeah I was starting too detailed and working out. I think an initial implementation could be to do how we handle listeners today which is to listen on 0.0.0.0 over ports 80 & 443 (configurable).

My suggestion is to allow L4 load balancers to be defined the same way, listening on ports that are defined in the CRD over 0.0.0.0. A user could add those ports to the Envoy service to expose them from an external load balancer if that was their environment.

This leaves the other bits like assigning IPs, etc, etc, etc to another controller or implementation based upon the environment, but is simple enough to give users a bit more functionality to fill in any gaps today.

[spines83]

Hey all! Just wanted to toss in another use case where this became an active issue.

Contour is the primary ingress controller on a cluster we're using and we needed to install GitLab on that cluster.

In order to clone/push projects from GitLab over SSH, we need to be able to run an SSH connection through an ingress controller to the workload. SSH uses its own non-TLS encryption so this has forced us into a situation where we need to run another ingress controller side-by-side (out of the box, GitLab will attempt to deploy another ingress controller).

In most of the environments I've worked in, folks prefer the ability to run one ingress controller where they can (and some will explicitly set up OPA/Kyverno policies to prevent additional ones from being created by users of the platform), but this has put us into a situation where we either need to run two ingress solutions side-by-side or strip out Contour and replace it with another solution.

Would be awesome if TCPProxy could be expanded to allow for non-TLS passthrough since folks running some flavor of git w/ SSH on their platforms is a pretty common use case.

[youngnick]

Thanks for the additional use case @spines83, that's very useful.

[github-actions]

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]

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