After adding password protection in the minimal security configuration, you’ll need to configure Transport Layer Security (TLS). The transport layer handles all internal communication between nodes in your cluster.
The transport layer relies on mutual TLS for both encryption and authentication of nodes. Correctly applying TLS ensures that a malicious node cannot join the cluster and exchange data with other nodes. While implementing username and password authentication at the HTTP layer is useful for securing a local cluster, the security of communication between nodes requires TLS.
Configuring TLS between nodes is the basic security setup to prevent unauthorized nodes from accessing to your cluster.
Complete the steps in Minimal security for the Elastic Stack to enable Elasticsearch security features on every node in your cluster. You can then encrypt communications between your nodes with TLS.
You only need to create passwords for the built-in users one time for the entire cluster.
You can add as many nodes as you want in a cluster but they must be able to communicate with each other. The communication between nodes in a cluster is handled by the transport module. To secure your cluster, you must ensure that internode communications are encrypted and verified, which is achieved with mutual TLS.
In a secured cluster, Elasticsearch nodes use certificates to identify themselves when communicating with other nodes.
The cluster must validate the authenticity of these certificates. The recommended approach is to trust a specific certificate authority (CA). When nodes are added to your cluster they must use a certificate signed by the same CA.
For the transport layer, we recommend using a separate, dedicated CA instead
of an existing, possibly shared CA so that node membership is tightly controlled. Use the
elasticsearch-certutil tool to
generate a CA for your cluster.
elasticsearch-certutiltool to generate a CA for your cluster.
When prompted, accept the default file name, which is
elastic-stack-ca.p12. This file contains the public certificate for your CA and the private key used to sign certificates for each node.
- Enter a password for your CA. You can choose to leave the password blank if you’re not deploying to a production environment.
- When prompted, accept the default file name, which is
Generate a certificate and private key for your node. You include the
elastic-stack-ca.p12output file that you generated in the previous step.
./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
- Enter the password for your CA, or press Enter if you did not configure one in the previous step.
Create a password for the certificate and accept the default file name.
The output file is a keystore named
elastic-certificates.p12. This file contains a node certificate, node key, and CA certificate.
Name of the CA file used to sign your certificates. The
default file name from the
elastic-certificates.p12file to the
ES_PATH_CONFdirectory on every node in your cluster.
The transport networking layer is used for internal communication between nodes in a cluster. When security features are enabled, you must use TLS to ensure that communication between the nodes is encrypted.
Now that you’ve generated a certificate authority and certificates, you’ll update your cluster to use these files.
Elasticsearch monitors all files such as certificates, keys, keystores, or
truststores that are configured as values of TLS-related node settings. If
you update any of these files, such as when your hostnames change or your
certificates are due to expire, Elasticsearch reloads them. The files are polled for
changes at a frequency determined by the global Elasticsearch
resource.reload.interval.high setting, which defaults to 5 seconds.
Complete the following steps for each node in your cluster. To join the
same cluster, all nodes must share the same
ES_PATH_CONF/elasticsearch.ymlfile and make the following changes:
cluster-namesetting and enter a name for your cluster:
node.namesetting and enter the name of the certificate that you generated for this node. For simplicity, it’s good practice for this value to match the certificate name that you defined in your
Add the following settings to enable internode communication and provide access to the node’s certificate:
xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.client_authentication: required xpack.security.transport.ssl.keystore.path: <node-name>.p12 xpack.security.transport.ssl.truststore.path: <node-name>.p12
If you entered a password when creating the node certificate, run the following commands to store the password in the Elasticsearch keystore:
./bin/elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password
./bin/elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password
- Complete the previous steps for each node in your cluster.
For example, if you installed Elasticsearch with an archive distribution (
.zip), you can enter
Ctrl+Con the command line to stop Elasticsearch.
You must perform a full cluster restart. Nodes that are configured to use TLS for transport cannot communicate with nodes that use unencrypted transport connection (and vice-versa).
Congratulations! You’ve encrypted communications between the nodes in your cluster and can pass the TLS bootstrap check.
To add another layer of security, Set up basic security for the Elastic Stack plus secured HTTPS traffic. In addition to configuring TLS on the transport interface of your Elasticsearch cluster, you configure TLS on the HTTP interface for both Elasticsearch and Kibana.