-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mTLS over TCP tunnel via HTTP/2 CONNECT #13001
Comments
I've stumbled on this as we were looking for the same functionality for the Kubernetes ingress controller Contour which leverages Envoy for it's data plane. Issue at projectcontour/contour#2885. I think you'll need |
Thanks @moderation for the information! I want to make sure my understanding is correct:
|
I might have confused things here. Your examples are based on the links from the documentation at https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/upgrades#tunneling-tcp-over-http-2 but it looks like you have added a HCM on the client side So thinking about this I'm not sure you can do a L4-7 mTLS chain with L3 TCP??? If what you are talking about is possible I would think you need the Definitely need to defer to @htuch and @alyssawilk on this one. |
Right, my example is based on the doc, but I extended in a way that basically the client-side Envoy converts the downstream TCP stream into a HTTP/2 stream (that's why it has two listeners); the server-side Envoy unwraps the TCP stream from the HTTP/2 stream then passes to the server upstream. |
yeah, I think I need to enable xfcc config in cluster_0 in addition to the tls config, do you know if there is a good example to enable xfcc ? |
I think it's probably worth explaining whose identity you are trying to verify/preserve. If it's only between the two Envoys, then I think you just need to set TLS transport socket for cluster_1 and listener_2. Why do you want to start the mTLS at cluster_0? I think that would only make sense if you want the TCP stream forwarded from cluster_2 to be TLS. |
Synced with @wlhee offline. The idea is to preserve an inner identity, associated with the original TCP stream, while client/server Envoy might have an outer TLS connection. I think mTLS from cluster_0 to listener_1, with XFCC, would provide you a way to propagate the identity of cluster_0 over the connection. If that's all you need, I think that works. If you need full tunneling of mTLS, I think you need to potentially do another loopback where you layer TLS on the TCP stream before wrapping with CONNECT. I'll defer to @lambdai and @alyssawilk on this one. |
Thanks @htuch I tried to use xfcc in cluster_0, but it doesn't seem like I am configuring things properly. It looks like cluster_0 can't talk to the loopback listener_1 due to cert enabled in cluster_0: client-side envoy config:
server-side envoy config:
|
@wlhee I think for |
Per offline discussion with @htuch to figure out. client envoy:
server envoy:
|
Hi, thanks to the TCP-tunnel via HTTP/2 CONNECT in Envoy, we can tunnel TCP over the following set up:
client -> (TCP) -> client-side Envoy -> (HTTP/2 CONNECT) -> server-side Envoy -> (TCP) -> server
Our question is how do we configure the Envoys to enable mTLS? It seems like the mTLS is always between a cluster and its immediate upstream?
Please see the example configs below. What we want to achieve to have mTLS between cluster_0 of client-side Envoy and listener2 of server-side Envoy.
Thanks for any tips!
The text was updated successfully, but these errors were encountered: