contour
contour copied to clipboard
projectcontour
Add support for TCP proxy without TLS
Describe the solution you'd like
It would be great to support TCP services that cant use TLS, SFTP or other legacy TCP protocols come to mind. I need to have a sftp backend and I cant route this traffic currently with contour which forces me to add an additional ingress controller for this alone.
Thank you for raising this issue. The question of TCP proxying without TLS encapsulation has come up a few times before, #891 for example.
To TCP forward protocols that don't have a TLS encapsulation would require dedicating a TCP port per backend service. Kubernetes already supports this natively with the Service object so my question to you is can you use a Service style Load Balancer to expose your SFTP service to the internet? If not, why not?
Hi @davecheney,
I am running k8s on baremetal and in an environment where metalb is not supported so unfortunately I dont have access to the server type LoadBalancer within my clusters.
Thank you for your reply. My follow up question is, in your bare metal environment, what are you using to expose Envoy’s HTTP and HTTPS ports to the internet?
On a side note, even if I could use a service style load balancer, i would still prefer / want to have all my external traffic to flow to my envoy edge proxy.
Is there something Contour specific that makes providing this while you are already supporting TCP with TLS inherently difficult ? I was actually surprised that Contour does not support cleartext / raw tcp while it now supports tcp with tls.
I have no idea if that helps or not and you are probably aware of this already but Ambassador which is also built on top of envoy do provide support for both cleartext and tls tcp connections.
On a side note, even if I could use a service style load balancer, i would still prefer / want to have all my external traffic to flow to my envoy edge proxy.
Would you be able to expand on why this is useful? It is logging? Is it rate limiting? Is it authentication?
Is there something Contour specific that makes providing this while you are already supporting TCP with TLS inherently difficult ? I was actually surprised that Contour does not support cleartext / raw tcp while it now supports tcp with tls.
To support proxying a raw TCP stream contour would have to ask Envoy to open a new port for each service to proxy. This is because without some kind of framing--this is what TLS give us--it is not possible to know where to send traffic arriving at an undiscriminated port. Hence, we need to assign a single port to a single tcp. This is a poor mans NAT.
Contour's goal is be a HTTP proxy. Our goal is not to provide a replacement for metallb or a tcp load balancer. We added TCP proxying via TLS because it was relatively straight forward. Adding support for non TLS encapsulated traffic would mean Contour would have to edit its own service document to open incoming ports to direct them to Envoy. This wouldn't work in the bare metal case and is pretty much left as an exercise to the operator to figure out how to forward random ports to Envoy pods.
Also, when you look at what we'd have to do to plumb individual ports down to Envoy just so it could proxy traffic onwards to a service, why not just plumb the traffic directly to the pod's cluster ip or node port directly?
Yes logging, monitoring and rate limiting. Having a single point of concern for all of this is super valuable imho.
I totally understand the requirement to dedicate a port to a service in that model and I understand your sentiment. I don't think the use case is a scenario where you deploy thousands of raw tcp services but just very tiny numbers of them (like 1-3), be it for a vpn, a ssh bastion or a sftp server. For those scenarios, mapping a tcp port to a service is not very problematic and from a operational standpoint having the traffic of those services still flow through Envoy is immensely valuable.
I believe most ingress controllers start with the same goal / mission as Contour but eventually do include support for tcp proxying to drive adoption because a lot of people still need to route some tcp services and they don't want to operate 2 ingress controllers or bypass it entirely in those cases.
Thanks for the clarification on how non trivial that issue would be and I understand why it may not be a priority at the moment. I just hope that at some point in the future, it will be considered and that maybe the prior art done by ambassador which is also open source could help to deliver it quicker.
Thank you for explaining your use case. I'm going to remove the waiting for info label from this issue as I think the use case is sufficiently clear.
Being straight with you, this is not a high priority, and involves some very large changes to the way Contour interacts with k8s -- for example, it would need to edit its own service document to have the cloud provider load balancer forward traffic to individual listeners. At the moment this is not on our roadmap, but I will keep this issue open for the product manager to consider.
We do not plan to implement this feature before Contour 1.0. Moving to the Unplanned milestone.