Using the TransportClient with ECK

Elastic Orchestration Elastic Cloud on Kubernetes (ECK)
1

We have a legacy application which uses the Java TransportClient to access the ES API on port 9300, which we would like to operate with the ES operator. It seems that the ES instance created by ECK only exposes the REST API on port 9200.

Is it possible to use the API on port 9300? I tried to expose it via a Service, but it is secured by client certificate authentication and I cannot figure out how to create a valid certificate.

2

Hi,
First of all, Transport Client is currently deprecated and we don't suggest to rely on it in the future.
If disabling client authentication is an option for you, then you can do it as described in https://www.elastic.co/guide/en/elasticsearch/reference/7.3/separating-node-client-traffic.html

3

Thanks for your prompt answer. I followed the instructions and disabled client certificate authentication, the application can now successfully connect to ES.

We are aware that the Transport Client is deprecated, but until the migration is implemented we need an intermediate solution.

4

What exactly did you do to make this work please? Looking at the referenced documentation, and hoping it also works for the 6.8.8 that I'm constrained to use, it looks like one puts

transport.profiles.client.xpack.security.ssl.client_authentication: none

somewhere, but where exactly in the Elasticsearch resource manifest does this go?

And even having done that, the connection has to be TLS, yes? So the client needs to either be modified to skip the CA check, or needs the CA certificate? Which is in the <cluster name>-es-transport-ca-internal secret? - have I got this right so far?

5

That would go to the config section of the nodeSet:

spec:
  nodeSets:
  - name: masters
    count: 3
    config:
      transport.profiles.client.xpack.security.ssl.client_authentication: none

Yes.
The transport networking layer is used for internal communication between nodes in a cluster. As ECK enables the security by default, you must use TLS to ensure that communication between the nodes is encrypted. And ECK does it for you.

Absolutely.

6

Thanks, I'd subsequently found the documentation of where to put that config.

The next problem is that the SAN of the server certificate does not of course match the name of the bodged service so the client drops the connection. So that's a change to the client code to bypass most of the checking - which, as I do have access to the client code, I can actually do (but haven't done yet).

7

But in fact I have not found any way to tell the Java transport client to ignore the server name mismatch. Has anyone solved this?