Contour TCP support for LDAP applications and traffic routing #4306
Comments
gnanirahulnutakki
added
kind/feature
|
Currently, Contour supports TCP ingress for TLS-wrapped protocols that support SNI only. This is because Contour currently only supports having Envoy listen on two ports, insecure and secure. The insecure port is expected to receive HTTP traffic, and the secure port is expected to received TLS traffic. Contour configures Envoy to use the SNI hostname that's send as part of the TLS handshake to distinguish between different routing chains. In order to serve plain TCP ports, Contour will need to be able to open extra ports on Envoy. This will require something like the design in #3263. Once that happens, Contour will support a way to specify what extra ports to open on Envoy's listen address. For them to pass TCP traffic, they'll need to be dedicated to a single protocol. This does have the further complication that without higher-layer protocol support, all the TCP connections will appear to come from Envoy. Contour does support configuring Envoy to use the PROXY protocol which gets around this problem, but this then also requires that the backend service speak the PROXY protocol too. To sum up this part of the answer, we should really have called We can (and probably will) add support for adding additional listeners in the future, which will mean that it will be possible to configure Contour to proxy TCP traffic. Because Contour usually requires at least one upstream load balancer (because its Envoys run in-cluster), when we do that, it won't be possible to have the original remote client address be visible at Layer 4 without the use of PROXY protocol. PROXY protocol requires:
Of course, if you are using a Layer 7 protocol that has some other way to retrieve the client IP, or the client IP doesn't matter, then what we will be able to add will work. To answer the other questions:
To answer your question in the shortest, and most likely least satisfying, way possible: Does Contour support TCP forwarding? It depends on what you're trying to forward. Edit: After writing this whole comment, I realized that you said that you mean LDAP in the title. 🤦 As I implied above, Contour should be able to forward LDAP as long as it's LDAPS, terminated at the backend system. To be honest, I'm not sure if or how well terminating LDAPS at Contour and forwarding LDAP to the backend would work, even aside from losing the client IP. |
|
I was trying to create a httpproxy with tcpproxy in this way apiVersion: projectcontour.io/v1 So according to what you explained this probably might or might not work |
|
It will not be very convenient but you could try something like this apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: example
namespace: default
spec:
virtualhost:
fqdn: ldap-app.example.com
tls:
passthrough: true
tcpproxy:
services:
- name: ldaps
port: 2636You would be able to use LDAPS only like @youngnick wrote and your LDAP client would need to use hostname |
|
I tried with the following manifest file but no luck, The TLS handshake does not seems to get through LOGS FROM APACHE DIRECTORY STUDIO: |
|
Could it be that you used Contour's HTTP port in Apache Directory Studio's connection settings instead of HTTPS port? I tried that config now myself and it works with some caveats:
|
|
I changed the fqdn to match the certificate name in my LDAP application server so manifest looks like this now And checked to see if it would work, Even this does not seems to work. Any ideas? |
|
Testing with |
|
The Contour project currently lacks enough contributors to adequately respond to all Issues. This bot triages Issues according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
github-actions
bot
added
the
lifecycle/stale
|
The Contour project currently lacks enough contributors to adequately respond to all Issues. This bot triages Issues according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
Please describe the problem you have
[A clear, concise, description of the problem you are facing. What is the problem that feature X would solve for you?]
Hi Guys, I was recently assigned a task which requires me to use Contour as ingress. Ours is a LDAP application per say and I need to use ingress for TCP traffic. Basically support for L4.
I asked this question on slack and was told this by steve sloka
" Hey, Contour supports TCP over TLS in our HTTPProxy CRD (https://projectcontour.io/docs/v1.19.1/config/api/#projectcontour.io/v1.TCPProxy)."
"Yup that’s in there but doesn’t mean it can’t change in the future. The idea now was to focus on L7 and get that right. There can be a lot to L4 load balancers which others in the community have focused on, however, I agree that there are places for L4 in an edge proxy that we’ve also see from other users."
"At the moment, you can do L4 over TLS via the TCPProxy details I mentioned earlier and we can chat about the L4 additions. Could you open an issue on that to track it better?"
I am in the process to creating this manifest using TCPproxy, but I would really appreciate an official documentation or assistance on this
My questions are:
Does contour support TCP ingress?
How reliable and accurate is it to use contour for TCP
Are there are examples where contour was deployed for kubernetes ingress manifests for TCP
I would really appreciate some guidance here
The text was updated successfully, but these errors were encountered: