WARNING: Version 5.6 of the Elastic Stack has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Setting Up SSL/TLS on a Cluster
editSetting Up SSL/TLS on a Cluster
editX-Pack security enables you to encrypt traffic to, from, and within your Elasticsearch cluster. Connections are secured using Transport Layer Security (TLS), which is commonly referred to as "SSL".
Clusters that do not have encryption enabled send all data in plain text including passwords.
To enable encryption, you need to perform the following steps on each node in the cluster:
- Generate a private key and X.509 certificate.
-
- Identify itself using its signed certificate.
- Enable SSL on the transport and HTTP layers.
- Restart Elasticsearch.
Node Certificates
editTLS requires X.509 certificates to perform encryption and authentication of the application that is being communicated with. In order for the communication between nodes to be truly secure, the certificates must be validated. The recommended approach for validating certificate authenticity in a Elasticsearch cluster is to trust the certificate authority (CA) that signed the certificate. By doing this, as nodes are added to your cluster they just need to use a certificate signed by the same CA and the node is automatically allowed to join the cluster. Additionally, it is recommended that the certificates contain subject alternative names (SAN) that correspond to the node’s ip address and dns name so that hostname verification can be performed.
In order to simplify the process of generating certificates for the Elastic Stack, a command
line tool, certgen
has been included with X-Pack. This tool takes care of the generating
a CA and signing certificates with the CA. certgen
can be used interactively or in a silent
mode through the use of an input file. The certgen
tool also supports generation of certificate
signing requests (CSR), so that a commercial or organization specific CA may be used to sign
the certificates. For more information, see certgen.
If you choose not to use certgen
, the certificates that you obtain must allow for both
clientAuth
and serverAuth
if the extended key usage extension is present. The certificates
need to be in PEM format. Although not required, it is highly recommended that the certificate contain
the dns name(s) and/or ip address(es) of the node so that hostname verification may be used.
Enabling SSL in the Node Configuration
editOnce you have the signed certificate, private key, and CA certificate you need to modify the node configuration to enable SSL.
To enable SSL, make the following changes in elasticsearch.yml
:
-
Specify the location of the node’s keystore and the password(s) needed to access the node’s certificate. For example:
xpack.ssl.key: /home/es/config/x-pack/node01.key xpack.ssl.certificate: /home/es/config/x-pack/node01.crt xpack.ssl.certificate_authorities: [ "/home/es/config/x-pack/ca.crt" ]
The full path to the node key file. This must be a location within the Elasticsearch configuration directory.
The full path to the node certificate. This must be a location within the Elasticsearch configuration directory.
An array of paths to the CA certificates that should be trusted. These paths must be a location within the Elasticsearch configuration directory.
-
Enable SSL on the transport networking layer to ensure that communication between nodes is encrypted:
xpack.security.transport.ssl.enabled: true
-
Enable SSL on the HTTP layer to ensure that communication between HTTP clients and the cluster is encrypted:
xpack.security.http.ssl.enabled: true
-
Restart Elasticsearch.
You must perform a full cluster restart. Nodes which are configured to use SSL/TLS cannot communicate with nodes that are using unencrypted networking (and vice-versa). After enabling SSL/TLS you must restart all nodes in order to maintain communication across the cluster.
All SSL related node settings that are considered to be highly sensitive and therefore are not exposed via the nodes info API.