TLS encryption for cluster communications
ECE ECK Self Managed
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 is fully 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 to Security features by deployment type.
The term transport 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, the transport layer refers to internal node-to-node communication, which occurs over port 9300. This communication uses the transport 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:
- The transport layer (defaults to port
9300), used for internal communication between nodes in the cluster. - The HTTP 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 own HTTP endpoint (defaults to port 5601) 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 Elastic Cloud Enterprise platform, and no configuration is required.
Elasticsearch transport security and TLS certificates are automatically configured by the operator, but you can still customize its service and CA certificates.
Elasticsearch transport security can be automatically configured, or manually set up by following the steps in Set up transport TLS.
For additional TLS configuration options, refer to Manage TLS encryption in self-managed deployments.
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, with several 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 be automatically configured, or manually set up by following the steps in Set 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 in Set up HTTPS > Encrypt traffic between your browser and Kibana.
For environments with stricter security requirements, refer to Mutual TLS authentication between Kibana and Elasticsearch.
For additional TLS configuration options, refer to Manage 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 to Manage security certificates.
ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like cert-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 to ECK 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 to Update TLS certificates for guidance on rotating or replacing them.