From version 5.0 onward, Shield is part of X-Pack. For more information, see Securing the Elastic Stack.
« Enabling Cipher Suites for Stronger Encryption Using IP Filtering »
Elastic Docs ›Shield [2.4] ›Securing Communications with Encryption and IP Filtering

Separating node to node and client traffic

edit

Separating node to node and client traffic

edit

Elasticsearch has the feature of so called tcp transport profiles. This allows Elasticsearch to bind to several ports and addresses. Shield extends on this functionality to enhance the security of the cluster by enabling the separation of node to node transport traffic from client transport traffic. This is important if the client transport traffic is not trusted and could potentially be malicious. To separate the node to node traffic from the client traffic, add the following to elasticsearch.yml:

transport.profiles.client: 
  port: 9500-9600 
  shield:
    type: client

client is the name of this example profile

The port range that will be used by transport clients to communicate with this cluster

A type of client enables additional filters for added security by denying internal cluster operations (e.g shard level actions and ping requests)

If supported by your environment, an internal network can be used for node to node traffic and public network can be used for client traffic by adding the following to elasticsearch.yml:

transport.profiles.default.bind_host: 10.0.0.1 
transport.profiles.client.bind_host: 1.1.1.1

The bind address for the network that will be used for node to node communication

The bind address for the network used for client communication

If separate networks are not available, then IP Filtering can be enabled to limit access to the profiles.

The tcp transport profiles also allow for enabling SSL on a per profile basis. This is useful if you have a secured network for the node to node communication, but the client is on an unsecured network. To enable SSL on a client profile when SSL is disabled for node to node communication, add the following to elasticsearch.yml:

transport.profiles.client.ssl: true

This enables SSL on the client profile. The default value for this setting is the value of shield.transport.ssl.

When using SSL for transport, a different set of certificates can also be used for the client traffic by adding the following to elasticsearch.yml:

transport.profiles.client.shield.truststore:
  path: /path/to/another/truststore
  password: changeme

transport.profiles.client.shield.keystore:
  path: /path/to/another/keystore
  password: changeme

To change the default behavior that requires certificates for transport clients, set the following value in the elasticsearch.yml file:

transport.profiles.client.shield.ssl.client.auth: no

This setting keeps certificate authentication active for node-to-node traffic, but removes the requirement to distribute a signed certificate to transport clients. Please see the Transport Client section.

Transport profiles also allow for a separate keystore and truststore to be used for HTTP traffic and node/transport client traffic:

shield.http.ssl: true
shield.transport.ssl: true
shield.ssl.keystore.path: /home/es/config/shield/node01_http.jks 
shield.ssl.keystore.password: myPass
transport.profiles.default:
  shield:
    keystore:
      path: /home/es/config/shield/node01_transport.jks 
      password: myOtherPass

The path to the keystore that contains the key and certificate for use on the HTTP layer

The path to the keystore that contains the key and certificate for use on the transport layer
« Enabling Cipher Suites for Stronger Encryption Using IP Filtering »