Manually configure security
editManually configure security
editSecurity needs vary depending on whether you’re developing locally on your laptop or securing all communications in a production environment. Regardless of where you’re deploying the Elastic Stack ("ELK"), running a secure cluster is incredibly important to protect your data. That’s why security is enabled and configured by default in Elasticsearch 8.0 and later.
If you want to use your own Certificate Authority (CA) or would rather manually configure security, the following scenarios provide steps for configuring TLS on the transport layer, plus securing HTTPS traffic if you want it.
If you configure security manually before starting your Elasticsearch nodes, the auto-configuration process will respect your security configuration. You can adjust your TLS configuration at any time, such as updating node certificates.
Basic security (Elasticsearch + Kibana)
editThis scenario configures TLS for communication between nodes. This security layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your Elasticsearch cluster.
Your external HTTP traffic between Elasticsearch and Kibana won’t be encrypted, but internode communication will be secured.
Basic security plus secured HTTPS traffic (Elastic Stack)
editThis scenario builds on the one for basic security and secures all HTTP traffic with TLS. 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.
If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption.
You then configure Kibana and Beats to communicate with Elasticsearch using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure.