Guide: Elasticsearch Security

Elasticsearch Security

Implementing data security will guard against those without authorized access, entities of corruption, and digital data theft. It endows software programs with administrative and access controls and logical security. Now more than ever, having security features is essential to every company across industries.

The good news is that there is no need to search outside the Elastic Stack security for data protection apps.

The Elasticsearch Basic Security capabilities are free and contain a lot of functionality to help you prevent or limit unauthorized access, protect data integrity by encrypting communication between nodes, and keep track of who did what with your stack and the data it stores.

Getting started with Elasticsearch security includes everything you need to keep your cluster safe, from Elasticsearch encryption, authentication, and backup.

In this article, you will learn the following:

What is Elasticsearch?

Elasticsearch is an open-source distributed search and analytics engine offered for free. Elasticsearch Security got enabled, resulting in a robust RESTful API for managing and working with the engine. Securing Elasticsearch means a fast, scalable, and secure search engine for your organization.

The Elasticsearch engine is in charge of data ingest, storage, and analysis. Elasticsearch is a powerful solo service, but it becomes more so when combined with its Elastic Stack sisters, Kibana and Logstash.

The Elasticsearch Principles

The Elastic Stack comprises many working components, including Elasticsearch nodes, Logstash instances, Kibana instances, Beats agents, and clients communicating with the cluster.

With that in mind, follow the Elasticsearch security principles to keep your Elasticsearch cluster safe:

Enable Security in Elasticsearch and Run it

Never run Elasticsearch without security turned on. Without protection, anyone that can send network activity to Elasticsearch can download, change, or even destroy any data in your cluster.

Use a Non-root User to Run Elasticsearch

Do not attempt to run Elasticsearch as the root user, as this will nullify any security measures and allow a hostile user to perform anything on your server. To operate Elasticsearch, you will need to create a dedicated, non-root user.

Keep Elasticsearch Safe from Public Internet Traffic

Even if security gets turned on, do not expose Elasticsearch to traffic from the public internet. Some people might write _search queries that could overwhelm an entire Elasticsearch cluster and bring it down, even though an application gets used to sanitize the requests to Elasticsearch.


Keep Elasticsearch as far away from unwanted users as possible, behind a firewall and a VPN (if needed to connect remotely). People who use internet-facing apps should run aggregations that have already been set up or not run aggregations.


Although you should avoid exposing Elasticsearch to the internet, you should also avoid exposing Elasticsearch to users. Instead, make queries on behalf of users using an intermediate application.

Implement Access Control based on Roles

Create user roles and grant appropriate privileges to ensure that authorized users only have access to the resources they require. This procedure evaluates whether the user who initiated an inbound request is authorized to execute it.

How to Enable Security in Elasticsearch

As previously stated, the first principle is to operate Elasticsearch with security enabled. Although Elasticsearch TLS configuration can be tricky, the Elastic Stack was designed to start with security enabled by default.


Simply starting Elasticsearch will allow you to enable and customize the security elements of the Elastic Stack. You can then enroll additional nodes by connecting a Kibana instance to your secured Elasticsearch cluster. With that, you will have password protection, Transport Layer Security (TLS)-secured inter-node communication, and encrypted communications between Elasticsearch and Kibana.


You can manually configure security to secure Elasticsearch clusters and any clients that communicate with your clusters if you wish to manage security yourself. Additional security mechanisms can be implemented, such as role-based access control, IP filtering, and auditing.

How to Manually Configure Security

Your security requirements will differ whether you create locally on your laptop or safeguard all communications in a production setting.


Irrespective of where you deploy the Elastic Stack, running a secure cluster is critical for data security. As a result, in Elasticsearch 8.0 and beyond, security is enabled and configured by default.

The auto-configuration process will follow your security settings if you set up security manually before starting your Elasticsearch nodes. At any time, you can modify the settings for your Elasticsearch TLS configuration. For example, you can change the certificates for your nodes.

Basic Security (Elasticsearch + Kibana)

This scenario makes sure that TLS gets set up for communication between nodes. This layer of security asks nodes to check their security certificates, which stops other nodes from entering your Elasticsearch cluster.


Remember that you will not be safe to send outside HTTP traffic between Elasticsearch and Kibana, but internal communication will be.

Basic Security + Secured HTTPS Traffic (Elastic Stack)

This scenario expands on the previous one by encrypting all HTTP traffic with TLS. You configure TLS on both Elasticsearch and Kibana’s HTTP interfaces and your Elasticsearch cluster’s transport interface.


This security is effective as it ensures that all communications into and out of your cluster are protected.

Security Settings in Elasticsearch

The Elasticsearch xpack security features get disabled by default with a basic or trial license. Use the configuration to enable security features.


You may set up settings to allow anonymous access and conduct message authentication, set up document and field level security, define realms, encrypt communications with SSL, and audit security events by learning how to enable xpack security in Elasticsearch.

You can add all these options to the elasticsearch.yml configuration file except for the security settings. On the other hand, you must add the security settings to the Elasticsearch Keystore.

General Security Settings

  • To enable the node’s Elasticsearch security features, set it to true. Security features are disabled if the value gets set to false, which is the default for basic and trial licenses. Moreover, you do not need to disable security features in those kibana.yml files because they impact all Kibana instances connected to this Elasticsearch instance.
  • A comma-separated list of settings not included in the cluster nodes info API responses. You can include numerous options in the list. For example, directory.ad1.* conceals all ad1 active directory realm settings. The API excludes all SSL settings.
  • This enables the use of fips mode. Set this to be true if you run this Elasticsearch instance on a JVM that supports FIPS 140-2.


Data security is a critical consideration in the age of the cloud, remote services, and the Internet of Things, and you must consider it from the beginning of any project.


In this regard, Elasticsearch has several security features to safeguard data and manage resource access. Many of them, such as role-based access control, are included in the default distribution for free.

Elasticsearch Security with Satori

Go here to learn more about how Satori helps secure your cloud data. Elasticsearch support is coming soon, and we’d love to understand your needs.

Last updated on

May 10, 2022

The information provided in this article and elsewhere on this website is meant purely for educational discussion and contains only general information about legal, commercial and other matters. It is not legal advice and should not be treated as such. Information on this website may not constitute the most up-to-date legal or other information. The information in this article is provided “as is” without any representations or warranties, express or implied. We make no representations or warranties in relation to the information in this article and all liability with respect to actions taken or not taken based on the contents of this article are hereby expressly disclaimed. You must not rely on the information in this article as an alternative to legal advice from your attorney or other professional legal services provider. If you have any specific questions about any legal matter you should consult your attorney or other professional legal services provider. This article may contain links to other third-party websites. Such links are only for the convenience of the reader, user or browser; we do not recommend or endorse the contents of any third-party sites.