Expose elasticsearch services directly to the client or place them behind middleware

Question

I am writing a client server application. I have configured the search service on the server. The client (iOS application) requests information from the elasticity search service. I have two options:

1. put the elastic-search behind a nginx server(as proxy server). 2. write an app running on the middle-ware to wrap the elastic-search APIs(only certain APIs that will be queried by the client). 

For option 1, the entire elastic search API will be exposed to the client and the public at the same time.

Which option to take? Or is there any other good practice to deal with this case?

Answer 1

In my opinion, you should never offer an ES-API to the public. That way, everyone can simply delete your indexes by changing your mappings and do whatever they would like to do ... It's just dangerous.

In addition, the power of this API may be too complex for some clients who simply want to perform some basic operations. Although I do not know your requirements, I would recommend that you include ES in your own REST-API, which will meet the specific needs of the client.

Answer 2

If your client application will use most or all of the Elasticsearch API, it makes sense to put it behind a proxy, for example, Nginx.

If the client application will work with Elasticsearch in the traditional sense (search, even updating documents), I would prefer to put in front of it a “smarter” proxy, i.e. what you call middleware written in Ruby, Python, etc. You have tighter control over the workflow here, although the Nginx proxy is very smart too.

The more important question is whether you agree to provide the Elasticsearch API to the client using HTTP Auth or token-based authentication. Thus, the credentials are clearly visible to the client, can be intercepted, etc.

Here is an example of OAuth-based authentication for Elasticsearch and JavaScript client applications in this article: JavaScript and Elasticsearch Web Applications . It uses Twitter @Anywhere (replaced by Sign in with Twitter) to authenticate the user, preventing him from bypassing the proxy server by intercepting credentials.