Securing Your Elasticsearch Cluster: A Step-by-Step Guide to Enabling HTTPS
In today’s data-driven world, securing your infrastructure is not an option—it’s a necessity. By default, Elasticsearch communicates over unencrypted channels, leaving sensitive data vulnerable to interception and man-in-the-middle attacks. Enabling HTTPS (SSL/TLS) is one of the most critical steps you can take to protect your data both in transit and within your cluster.
This guide provides a clear, actionable walkthrough for configuring HTTPS on your Elasticsearch nodes, transforming your cluster from a security risk into a secure fortress.
Why Encrypting Elasticsearch Traffic is Non-Negotiable
Before diving into the configuration, it’s essential to understand what you’re protecting. Unencrypted communication between your application, Kibana, and the Elasticsearch nodes means that every query, every document, and every credential is sent in plain text.
Enabling SSL/TLS encryption ensures:
- Confidentiality: Prevents unauthorized parties from eavesdropping on the data exchanged between nodes or between clients and the cluster.
- Integrity: Guarantees that the data sent is the same as the data received, without any modification in transit.
- Authentication: Verifies that your clients are communicating with a legitimate Elasticsearch node and not an imposter.
Failing to implement this basic security layer can lead to data breaches, compliance violations, and a significant loss of trust.
Step 1: Generating the Necessary Certificates
The foundation of SSL/TLS is a set of digital certificates. You will need a Certificate Authority (CA) to sign certificates for each node in your cluster. Elasticsearch provides a convenient utility to handle this process.
First, you’ll generate a CA certificate. This acts as the root of trust for your cluster.
- Navigate to your Elasticsearch home directory.
- Run the
elasticsearch-certutiltool to create the CA.
./bin/elasticsearch-certutil ca
This command will prompt you for a password and generate a file named elastic-stack-ca.p12. This file contains your CA’s public certificate and private key. Secure this file, as it is the key to your cluster’s security.
Next, you need to generate a signed certificate and private key for your Elasticsearch node(s).
./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
The utility will ask for the password for the CA file you just created. It will also prompt you for details about the node, such as its DNS name and IP address. It is crucial to provide all DNS names and IP addresses that will be used to access this node.
This process will create a new file named elastic-certificates.p12. This file is a PKCS#12 keystore that contains the node’s certificate, the node’s private key, and the CA certificate.
Step 2: Distribute Certificates and Configure elasticsearch.yml
Copy the newly created elastic-certificates.p12 file to the configuration directory of each node in your cluster (e.g., /etc/elasticsearch/).
Now, open the main configuration file, elasticsearch.yml, to enable the security features and tell Elasticsearch where to find the certificates. Add the following lines:
# Enable X-Pack Security
xpack.security.enabled: true
# Enable SSL/TLS for the Transport Layer (Node-to-Node Communication)
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12
# Enable SSL/TLS for the HTTP Layer (Client-to-Node Communication)
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: elastic-certificates.p12
xpack.security.http.ssl.truststore.path: elastic-certificates.p12
Breaking down the configuration:
xpack.security.enabled: true: This is the master switch that turns on all security features.xpack.security.transport.ssl.enabled: true: This encrypts communication between nodes in the cluster (port 9300).xpack.security.http.ssl.enabled: true: This encrypts communication between clients (like your browser or application) and the nodes (port 9200).keystore.path: This points to the file containing the node’s certificate and private key.truststore.path: This points to the file containing the certificates of trusted CAs. In this simple setup, the keystore and truststore are the same file.
Step 3: Restart and Verify Your Secure Cluster
After saving the elasticsearch.yml file on all nodes, you must restart the Elasticsearch service for the changes to take effect.
sudo systemctl restart elasticsearch
Once the service is back up, you can verify that HTTPS is working correctly. The easiest way is to use curl. Remember to use https in the URL and provide the credentials for a user, such as the built-in elastic superuser.
curl --cacert /path/to/your/ca/certificate.crt -u elastic https://your_elasticsearch_host:9200
Alternatively, if you don’t want to validate the CA for a quick test, you can use the -k (or --insecure) flag:
curl -k -u elastic https://your_elasticsearch_host:9200
When prompted, enter the password for the elastic user. If the configuration is correct, you will receive a successful JSON response with your cluster information. Congratulations, your Elasticsearch cluster is now communicating over a secure, encrypted channel!
Essential Security Best Practices
Enabling HTTPS is a great first step, but true security is a continuous process. Keep these additional tips in mind:
- Set Strong Passwords: Immediately after enabling security, set strong, unique passwords for all built-in users. Use the
elasticsearch-setup-passwordsutility for an easy setup. - Implement Role-Based Access Control (RBAC): Don’t use the
elasticsuperuser for your applications. Create specific roles with the minimum required permissions for different users and services. - Secure Your Keystore Files: The
.p12files contain your private keys. Ensure their file permissions are tightly restricted so that only the Elasticsearch user can read them. - Regularly Rotate Certificates: Certificates expire. Establish a process for renewing and deploying new certificates before the old ones become invalid to avoid service interruptions.
Source: https://kifarunix.com/easily-configure-elasticsearch-https-connection/
