66 lines
3.4 KiB
Plaintext
66 lines
3.4 KiB
Plaintext
|
[[separating-node-client-traffic]]
|
||
|
|
=== Separating node to node and client traffic
|
||
|
|
|
||
|
|
Elasticsearch has the feature of so called {ref}/modules-transport.html#_tcp_transport_profiles[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`:
|
||
|
|
|
||
|
|
[source, yaml]
|
||
|
|
--------------------------------------------------
|
||
|
|
transport.profiles.client<1>:
|
||
|
|
port: 9500-9600 <2>
|
||
|
|
shield:
|
||
|
|
type: client <3>
|
||
|
|
--------------------------------------------------
|
||
|
|
<1> `client` is the name of this example profile
|
||
|
|
<2> The port range that will be used by transport clients to communicate with this cluster
|
||
|
|
<3> 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`:
|
||
|
|
[source, yaml]
|
||
|
|
--------------------------------------------------
|
||
|
|
transport.profiles.default.bind_host: 10.0.0.1 <1>
|
||
|
|
transport.profiles.client.bind_host: 1.1.1.1 <2>
|
||
|
|
--------------------------------------------------
|
||
|
|
<1> The bind address for the network that will be used for node to node communication
|
||
|
|
<2> The bind address for the network used for client communication
|
||
|
|
|
||
|
|
If separate networks are not available, then <<ip-filtering, 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`:
|
||
|
|
[source, yaml]
|
||
|
|
--------------------------------------------------
|
||
|
|
transport.profiles.client.ssl: true <1>
|
||
|
|
--------------------------------------------------
|
||
|
|
<1> 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`:
|
||
|
|
[source, yaml]
|
||
|
|
--------------------------------------------------
|
||
|
|
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:
|
||
|
|
|
||
|
|
[source, yaml]
|
||
|
|
--------------------------------------------------
|
||
|
|
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, Transport Client>> section.
|