How do I enable remote access in Elasticsearch 5.2.0 from selected devices/computers only?

Question

Currently, I am running elasticsearch 5.2.0 in my digital ocean server.To remotely access the rest apis of elasticsearch, I made following change in config/elasticsearch.yml file:

network.host: 0.0.0.0

With this change, I am able to access the elasticsearch apis from anywhere using request:

http://server_url:9200/......

But, I want to access the elasticsearch apis only from local and selected devices/computers.

for eg: to access only from localhost(within server) and computerA, I have tried configuring as:

network.host: [_computerAIp_,_local_]

But its not working. How do I configure to achieve this requirement?

Answer 1

elasticsearch network.host settings in elasticsearch.yml is to set bind address for incoming http traffic and node to node communication.

From the look of your bit of code it seems you are misinterpreting it with ip address of the clients for ip filtering.

Here in elasticsearch.yml configuration you can do the following -

1) change http traffic port (default is 9200) for incoming http traffic using http.port: 9200.

2) change tcp port for transport clients for node to node communication using transport.tcp.port: 9300.

3) you can change elasticsearch bind address for elasticsearch server where to listen for traffic using network.bind_host: 192.168.0.1. You can change this to 'network.bind_host: localhost' to restrict public access.

More more detailed info on configuration please refer this and official documentation.

Now to achieve what you are trying i suggest you to use shield plugin which now comes free with X-Pack. Shield offers IP filtering support where you can define IP address who can access your elasticsearch.

Shield plugin will allow you to block, allow ip addresses for accessing your elasticsearch server by extending the same elasticsearch.yml file. After successfully installing shield plugin you will be able to use shield module in elasticsearch.yml file.

shield.transport.filter.enabled: false
shield.http.filter.enabled: true
shield.transport.filter.allow: [ "192.168.0.1", "192.168.0.2", "192.168.0.3", "192.168.0.4" ]
shield.transport.filter.deny: _all

Now these settings in elasticsearch.yml will be hard settings and after every change you may have to restart your server. Since you mentioned selected devices and computers and if the IP address for those devices changes dynamically. Then elastic also expose setting/configuring/changing IP address for IP filtering over their REST api as follows where you can change IP addresses on the fly without any restart

curl -XPUT localhost:9200/_cluster/settings -d '{
    "persistent" : {
        "shield.transport.filter.allow" : "172.16.0.0/24"
    }
}'

curl -XPUT localhost:9200/_cluster/settings -d '{
    "persistent" : {
        "shield.transport.filter.enabled" : false
    }
}'

This nice REST api for dynamically changing IP address for elastic along with other features of shield like authentication, authorization, document level roles can help you build a really fancy console interface/application for managing your elasticsearch cluster.

Please also refer the elasticsearch shield ip filtering documentation for more configuration info.

Hope this helps.

Answer 2

No, you couldn't do that from the Elasticsearch configuration. One possible way is to use some HTTP server, which will provide firewall functionality, e.g. Apache HTTPD or Nginx.

Why you coudln't user network.bind_host

This specifies which network interface(s) a node should bind to in order to listen for incoming requests. A node can bind to multiple interfaces, e.g. two network cards, or a site-local address and a local address.

It means, that if you deploy your ES on some server, you could, for example, bind it to the localhost, or to 89.2.34.3 (just an example). In first case, it will be reachable only from localmachine, second one could allow to reach it from the internet. But it will not help you to create set of rules which machines/devices could reach it and which couldn't.