2017-04-06 21:29:29 -04:00
|
|
|
[[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]
|
|
|
|
that allows it to bind to several ports and addresses. {security} 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>
|
2017-07-06 23:33:35 -04:00
|
|
|
xpack.security:
|
2017-04-06 21:29:29 -04:00
|
|
|
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> Categorizes the profile as a `client`. This accounts for additional security
|
|
|
|
filters by denying request attempts on for internal cluster operations
|
|
|
|
(e.g shard level actions and ping requests) from this profile.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.xpack.security.ssl.truststore:
|
|
|
|
path: /path/to/another/truststore
|
2017-06-29 16:27:57 -04:00
|
|
|
password: x-pack-test-password
|
2017-04-06 21:29:29 -04:00
|
|
|
|
|
|
|
transport.profiles.client.xpack.security.ssl.keystore:
|
|
|
|
path: /path/to/another/keystore
|
2017-06-29 16:27:57 -04:00
|
|
|
password: x-pack-test-password
|
2017-04-06 21:29:29 -04:00
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
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.xpack.security.ssl.client_authentication: 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.
|