TLS encryption for cluster communications
This page explains how to secure communications and set up TLS certificates in your Elastic Stack deployments.
For Elastic Cloud Hosted deployments and Elastic Cloud Serverless projects, communication security isfully managed by Elastic with no configuration required, including TLS certificates.
For ECE, ECK, and self-managed deployments, some of this process can be automated, with opportunities for manual configuration depending on your requirements. This page provides specific configuration guidance to secure the various communication channels between components.
For a complete comparison of security feature availability and responsibility by deployment type, refer toSecurity features by deployment type.
The termtransport can be confusing in Elasticsearch because it's used in two different contexts:
- Transport Layer Security (TLS) is an industry-standard protocol that secures network communication. It's the modern name for SSL, and the Elastic documentation uses the terms TLS and SSL interchangeably.
- In Elasticsearch, thetransport layer refers to internal node-to-node communication, which occurs over port 9300. This communication uses thetransport interface, which implements a binary protocol specific to Elasticsearch.
Keep this distinction in mind when configuring security settings.
Both Elasticsearch and Kibana, the core components of the Elastic Stack, expose service endpoints that must be secured. Elasticsearch handles traffic at two levels:
- Thetransport layer (defaults to port
9300), used for internal communication between nodes in the cluster. - TheHTTP layer (defaults to port
9200), used by external clients — including Kibana — to send requests using the REST API.
Additionally, Kibana functions as a web server, exposing its ownHTTP endpoint (defaults to port5601) to users, and also acts as a client when sending requests to Elasticsearch.
To ensure secure operation, it’s important to understand the communication channels and their specific security requirements.
| Channel | Description | TLS requirements |
|---|---|---|
| Elasticsearch transport layer | Communication between Elasticsearch nodes within a cluster | Mutual TLS/SSL required for multi-node clusters |
| Elasticsearch HTTP layer | Communication between external clients and Elasticsearch through the REST API | TLS/SSL optional (but recommended) |
| Kibana HTTP layer | Communication between external browsers or REST clients and Kibana | TLS/SSL optional (but recommended) |
The transport layer is used for communication between Elasticsearch nodes in a cluster. It relies on mutual TLS for both encryption and authentication of nodes.
Securing this layer prevents unauthorized nodes from joining your cluster and protects internode data. While implementing username and password authentication at the HTTP layer is useful for securing external access, the security of communication between nodes requires TLS.
The way that transport layer security is managed depends on your deployment type:
Elasticsearch transport security is fully managed by Elastic, and no configuration is required.
Elasticsearch transport security is fully managed by the Elastic Cloud Enterprise platform, and no configuration is required.
Elasticsearch transport security and TLS certificates are automatically configured by the operator, but you can stillcustomize the Elasticsearch transport service, certificate authority, and certificates.
Transport connections between Elasticsearch nodes are security-critical and you must protect them carefully. Malicious actors who can observe or interfere with node-to-node transport traffic can read or modify cluster data. A malicious actor who can establish a transport connection might be able to invoke system-internal APIs, including APIs that read or modify cluster data.
If you choose to issue node transport certificates using an external CA, then carefully reviewUsing an external certificate authority to secure node-to-node connections to ensure that your certificates meet the security requirements for transport connections.
Elasticsearch transport security can beautomatically configured, or manually set up by following the steps inSet up transport TLS.
For additional TLS configuration options, refer toManage TLS encryption in self-managed deployments.
Transport connections between Elasticsearch nodes are security-critical and you must protect them carefully. Malicious actors who can observe or interfere with node-to-node transport traffic can read or modify cluster data. A malicious actor who can establish a transport connection might be able to invoke system-internal APIs, including APIs that read or modify cluster data.
If you choose to issue node transport certificates using an external CA, then carefully reviewUsing an external certificate authority to secure node-to-node connections to ensure that your certificates meet the security requirements for transport connections.
The HTTP layer includes the service endpoints exposed by both Elasticsearch and Kibana, supporting communications such as REST API requests, browser access to Kibana, and Kibana’s own traffic to Elasticsearch. Securing these endpoints helps prevent unauthorized access and protects sensitive data in transit.
While HTTP TLS encryption is optional in self-managed environments, it is strongly recommended for both production and non-production deployments. Even in non-production environments, unsecured endpoints can expose sensitive data or introduce avoidable risks.
The way that HTTP layer security is managed depends on your deployment type:
HTTP TLS for Elasticsearch and Kibana is fully managed by Elastic. No configuration is required.Kibana instances are automatically configured to connect securely to Elasticsearch, without requiring manual setup.
HTTP TLS for deployments is managed at the platform proxy level. Refer to these guides for ECE-specific security customizations:
Kibana instances are automatically configured to connect securely to Elasticsearch, without requiring manual setup.
HTTP TLS is automatically enabled for Elasticsearch and Kibana using self-signed certificates, withseveral options available for customization, including custom certificates and domain names.
Kibana instances are automatically configured to connect securely to Elasticsearch, without requiring manual setup.
HTTP TLS certificates for Elasticsearch can beautomatically configured, or manually set up by following the steps inSet up HTTP SSL.
Kibana acts as both an HTTP client to Elasticsearch and a server for browser access. It performs operations on behalf of users, so it must be properly configured to trust the Elasticsearch certificates, and to present its own TLS certificate for secure browser connections. These configurations must be performed manually in self-managed deployments.
The automatic configuration does not enable TLS on the Kibana HTTP endpoint. To encrypt browser traffic to Kibana, follow the steps inSet up HTTPS > Encrypt traffic between your browser and Kibana.
For environments with stricter security requirements, refer toMutual TLS authentication between Kibana and Elasticsearch.
For additional TLS configuration options, refer toManage TLS encryption in self-managed deployments.
Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. Each deployment type provides different tools or responsibilities for managing certificates lifecycle.
Certificate lifecycle is fully managed by Elastic, including renewal and rotation.
In ECE, the platform automatically renews internal certificates. However, you must manually renew your custom proxy and Cloud UI certificates. For more details, refer toManage security certificates.
ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools likecert-manager, or using your own custom certificates. Custom HTTP certificates require manual management.
ECK automatically rotates any certificates and CAs that were generated by the operator and are under its management.
For certificate management configuration options, refer toECK configuration flags.
You are responsible for certificate lifecycle management, including monitoring expiration dates, renewing certificates, and redeploying them as needed. If you used Elastic tools to generate your certificates, refer toUpdate TLS certificates for guidance on rotating or replacing them.