How to secure an Internet-facing Elastic Search implementation in a shared hosting environment? [closed]

Question

I've been going over the documentation for Elastic Search and I'm a big fan and I'd like to use it to handle the search for my ASP.NET MVC app.

That introduces a few interesting twists, however. If the ASP.NET MVC application was on a dedicated machine, it would be simple to spool up an instance of Elastic Search and use the TCP Transport to connect locally.

However, I'm not on a dedicated machine for the ASP.NET MVC application, nor does it look like I'll move to one anytime soon.

That leaves hosting Elastic Search on another machine (in the *NIX world) and I would probably go with shared hosting there.

One of the biggest things lacking from Elastic Search, however, is the fact that it doesn't support HTTPS and basic authentication out of the box. If it did, then this question wouldn't exist; I'd simply host it somewhere and make sure to have an incredibly secure password and HTTPS enabled (possibly with a self-signed certificate).

But that's not the case.

That given, what is a good way to expose Elastic Search over the Internet in a secure way?

Note, I'm looking for something that hopefully, will not require writing code to provide shims for the methods that I want (in other words, writing forwarders).

Answer 1

A plugin for elasticsearch that allows you to replace the HTTP transport with an embedded instance of Jetty is now available.

Because it uses Jetty to handle the HTTP transport, it can handle SSL connections as well as be configured for authentication.

---

(Note, the following is still sound advice, in that it's generally good practice to abstract your operations out in this manner)

After a number of discussions on the ElasticSearch mailing list, I've discovered that the current solution is to host ElasticSearch behind another application layer and then to secure that layer.

The reasoning is solid; ElasticSearch is akin to a database, and you wouldn't make your database public-facing to all.

Something that I (and others) trip up on is that because ElasticSearch uses HTTP as a transport and uses JSON as the syntax for operations, that ElasticSearch is meant to be public-facing.

However, there is currently a request to add HTTPS transport support (assuming a certificate is provided) along with basic (digest) authentication.