Support SNI on transport TLS connection

[sventschui]

Describe the feature:

The transport connection should support SNI when configured to use TLS

Elasticsearch version (bin/elasticsearch --version):

Version: 7.6.1, Build: default/rpm/aa751e09be0a5072e8570670309b1f12348f023b/2020-02-29T00:15:25.529771Z, JVM: 13.0.2

Plugins installed: default rpm install

JVM version (java -version):

openjdk 13.0.2 2020-01-14
OpenJDK Runtime Environment AdoptOpenJDK (build 13.0.2+8)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 13.0.2+8, mixed mode, sharing)

OS version (uname -a if on a Unix-like system): CentOS 7

Description of the problem including expected versus actual behavior:

I expect the transport connection to use SNI when connecting to a peer. Currently it does not send any SNI headers

Steps to reproduce:

Can't come up with a simple repro case. I guess the easiest would be to setup a cluster and a haproxy that proxies to the nodes using SNI

Provide logs (if relevant):

n/a

[astefan]

I believe this is already supported as part of #32517 with docs being added with #40281.

[elasticmachine]

Pinging @elastic/es-distributed (:Distributed/Network)

[elasticmachine]

Pinging @elastic/es-security (:Security/Network)

[sventschui]

Hi @astefan. Thanks for the fast reply. To clarify things: I do not want to configure a remote cluster. I try to setup a coordinator only node that connects to the other ones through a k8s ingress that requires SNI. When configuring the nodes in discovery.seed_hosts the connection fails as the k8s ingress (haproxy) can not detect the pod to route to since SNI headers seem to be missing

[ywelsch]

@sventschui can you explain why you're setting up nodes that way? Nodes in a cluster are supposed to be part of the same network. Nodes in a cluster also need to be able to bidirectionally establish connections amongst each other. It sounds to me that what you're trying to do (unidirectional connect) would be better accomplished with the remote cluster feature.

[sventschui]

We have a 2 DC setup where we want a HA setup of elasticsearch. When one DC fails there still needs to be a quorum. We have the possibility to (1) use a VM that can run on both sides, but the SLA with the infra provider is up to 24h recovery time or (2) run a coordinator only node on an OpenShift Platform which is hosted in the same 2 DCs. The OpenShift Nodes can connect to the VMs on any Port but traffic to OpenShift is only allowed through an ingress on Port 443 that does SNI based load balancing. The idea is to run the coordinator only node on OpenShift and use Port 443 as the transport port. Do you see a better approach?

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[elasticsearchmachine]

Pinging @elastic/es-distributed (Team:Distributed)

[DaveCTurner]

We have a 2 DC setup where we want a HA setup of elasticsearch. When one DC fails there still needs to be a quorum.

This isn't even theoretically possible. See these docs for more information.

traffic to OpenShift is only allowed through an ingress on Port 443 that does SNI based load balancing

I don't think we should offer support for proxies between nodes within a cluster (at least not at layer 4 and up where this kind of feature would be needed). This kind of network policy is just unreasonably restrictive, and the solution is to fix the policy rather than to put effort into working around it within Elasticsearch. I could have seen some value in doing this for the transport client (but not now it's deprecated) and we already support SNI for remote clusters, so I think we shouldn't take any action here.

[original-brownbear]

For the reasons above we do not believe this is something we want to do so I'm closing this.