TCP SNI for Kubernetes?

[hapnermw]

Currently k8s ingress only supports HTTPS SNI.

I need k8s support for TLS SNI such that I can dynamically create TCP services with virtual server names and have a dynamically created TCP SNI reverse proxy dispatch connections to the correct k8s service.

I see that the linked-tcp beta is available and supports SNI. I see that linked-tcp integrates with the k8s API via namerd. I see some info on configuring namerd for k8s.

Since I’m hosting k8s on AWS, I’m assuming that the I would be using a loadbalancer service (that creates an ELB instance) as the internet entry point for TCP connections. This would load balance connections across instances of linked-tcp (that have been plumbed-into k8s via namerd).

What I don’t see is the full set of k8s resources that are required to get this to work.

Has anyone done this? What is the best way to get this configured?

[olix0r]

Hi @hapnermw!

Currently, linkerd-tcp supports SNI insofar as a server may support multiple named certs. However, currently (or at least the last I looked), rustls does not expose the server name that was negotiated to the application, so linkerd can't yet route on this name dynamically.

I'd really like to support this type of configuration, but we need to get some changes into the libraries we depend on. The good news is that we're currently sponsoring some work on these projects that should make this a closer reality in the coming weeks.

[hapnermw]

Oliver, thanks for the explanation. Assuming that Tokio is updated to expose the TLS SNI value to linked-tcp, I think you are saying that linkerd-tcp SNI routing would likely be implemented soon after. Is this correct? In this thread I had asked a few general linkerd-tcp/namerd k8s config questions. Can you give me some pointers on how to resolve these?

…

On Tue, Aug 15, 2017 at 12:56 PM, Oliver Gould ***@***.***> wrote: Hi @hapnermw <https://github.com/hapnermw>! Currently, linkerd-tcp supports SNI insofar as a server may support multiple named certs. However, currently (or at least the last I looked), rustls does not expose the server name that was negotiated to the application, so linkerd can't *yet* route on this name dynamically. I'd really like to support this type of configuration, but we need to get some changes into the libraries we depend on. The good news is that we're currently sponsoring some work on these projects that should make this a closer reality in the coming weeks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#71 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAySh4Hs2MPVUkbWKXOxkYiBCHWnkGu-ks5sYff0gaJpZM4Ov8_t> .

[briansmith]

PR #76 shows that the SNI information is exposed to the application by the underlying library (Rustls).