Best practices for Elasticsearch security

In the early days of Elasticsearch, security features were less robust than those of the latest versions. For instance, versions prior to version 6.3 did not include the open-source X-Pack extension. As of version 8.0, X-Pack has been deprecated, with its features now integrated into the Elasticsearch API.

With Elasticsearch 8.0 and above, security features are enabled by default. This evolution reflects modern data protection approaches, providing sophisticated security solutions to meet large organizations’ demands.

Security becomes crucial when handling confidential and vital data within your Elasticsearch dataset. Data breaches often stem from neglect and a poor understanding of security requirements, making robust security essential to your technology strategy. Implementing security involves costs in CPU, memory, hardware, and expertise. However, with decreasing hardware costs, Elasticsearch’s default security features highlight the necessity of strong data protection.

1. Install Elasticsearch with security enabled

When you first install Elasticsearch, security is automatically configured. This includes encryption for communication between nodes and clients. The system generates private and public certificates and a strong, randomly generated password. Below is an excerpt from the installation log of a successful Elasticsearch installation on Ubuntu Linux:

……..

The following NEW packages will be installed:
  elasticsearch
0 upgraded, 1 newly installed, 0 to remove and 184 not upgraded.
Need to get 596 MB of archives.
After this operation, 1234 MB of additional disk space will be used.
Get:1 https://artifacts.elastic.co/packages/8.x/apt stable/main amd64 elasticsearch amd64 8.7.0 [596 MB]
Fetched 596 MB in 13s (46.7 MB/s)
Selecting previously unselected package elasticsearch.
(Reading database ... 72764 files and directories currently installed.)
Preparing to unpack .../elasticsearch_8.7.0_amd64.deb ...
Creating elasticsearch group... OK
Creating elasticsearch user... OK
Unpacking elasticsearch (8.7.0) ...
Setting up elasticsearch (8.7.0) ...
--------------------------- Security autoconfiguration information ------------------------------

Authentication and authorization are enabled.
TLS for the transport and HTTP layers is enabled and configured.

The generated password for the elastic built-in superuser is : JeZrDh=R5vQlIfH_49d1

If this node should join an existing cluster, you can reconfigure this with
'/usr/share/elasticsearch/bin/elasticsearch-reconfigure-node --enrollment-token <token-here>'
after creating an enrollment token on your existing cluster.

You can complete the following actions at any time:

Reset the password of the elastic built-in superuser with
'/usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic'.

Generate an enrollment token for Kibana instances with
 '/usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana'.

Generate an enrollment token for Elasticsearch nodes with
'/usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s node'.

-------------------------------------------------------------------------------------------------
……..

It installs the Elasticsearch package and sets up security autoconfiguration for the following:

• Sets up TLS for transport and HTTP layers for communication with clients.
• Enables TLS/SSL on the transport layer for node-to-node communication.
• Sets token enrollment for authentication, such as in Kibana.
• Generates a strong password for the superuser.

If you want to change any of these autoconfiguration values, you can check your /etc/elasticsearch/elasticsearch.yml configuration file.

Elasticsearch uses X-Pack for encrypted communication. X-Pack is an Elastic Stack extension that provides security, alerting, monitoring, reporting, machine learning, and many other capabilities.  

As of Elasticsearch version 8.0, X-Pack is bundled and integrated by default, ensuring that security features are enabled out-of-the-box unless explicitly disabled. 

X-Pack is free with Elasticsearch, and starting with version 8.0, security features are inherently part of the Elasticsearch ecosystem. You can confirm if security is enabled during a fresh installation by checking the configuration:

# grep 'xpack.security.enabled' /etc/elasticsearch/elasticsearch.yml
xpack.security.enabled: true

If xpack.security.enabled is set to true, security is active.

The X-Pack extension also handles the transport and communication encryption security layer in Elasticsearch, and this is verified in the configuration file as shown below:

# grep 'xpack.security.' /etc/elasticsearch/elasticsearch.yml
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.client_authentication: required
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: http.p12

Once you set xpack.security.enabled to false, you disable the security features of your Elasticsearch installation.

2. Make sure you restrict administrative access

During the autoconfiguration process or installation of Elasticsearch on Linux, a system user named elasticsearch is created. To prevent mistakes and exposure to data breaches, ensure that this user is solely responsible for any Elasticsearch files and processes.

During installation, a superuser or built-in user named elastic, as shown previously with a generated password, is created. This user has administrator privileges for the overall management of your Elasticsearch. It’s crucial to keep this password secure and share it only with limited users who have the capability and expertise to protect and manage your Elasticsearch nodes. To safely store your passwords, you can use tools such as HashiCorp Vault, 1Password, KeePass, NordPass, or similar technologies.

3. Set strong passwords

If you already have strong passwords and prefer to use them instead of the randomly generated ones, you can optionally reset the password of your choice. Elasticsearch provides a utility tool to reset passwords. The binaries and utilities are located in /usr/share/elasticsearch/bin/. Resetting the password is straightforward, as shown in the example below:

# /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic -i
This tool will reset the password of the [elastic] user.
You will be prompted to enter the password.
Please confirm that you would like to continue [y/N]y


Enter password for [elastic]:
Re-enter password for [elastic]:
Password for the [elastic] user successfully reset.

4. Limit access to your Elasticsearch nodes

You can reset the password using Elasticsearch’s utility tools. However, consider the potential risks if a server is breached and taken over by an intruder or hacker, leading to data being stolen, exploited, or held for ransom.

To prevent such scenarios, ensure that access to your Elasticsearch nodes is restricted to dedicated personnel. Only DevOps engineers or Elasticsearch DBAs should have access to detailed information such as passwords and filesystem permissions. The directory and OS user should be accessible only to individuals with admin or superuser privileges.

Additionally, files containing credentials, such as usernames and passwords, should not be globally readable or exposed. For example, the Kibana configuration file (/etc/kibana/kibana.yml) should set its filesystem permissions so that only the owner and appropriate group can read it. This minimizes the risk of unauthorized access.

5. Using enrollment tokens to interact with Elasticsearch nodes

One great feature of Elasticsearch is the ability to use tokens for authentication when joining and communicating with an existing Elasticsearch cluster with enabled security features. The Elastic Stack security features authenticate users using realms and one or more token-based authentication services. These services manage and authenticate tokens. 

You can attach these tokens to requests sent to Elasticsearch and use them as credentials. When Elasticsearch receives a request that requires authentication, it consults the token-based authentication services first and then the realm chain.

For an Elasticsearch cluster, using enrollment tokens with a fresh install of Elasticsearch where autoconfiguration is enabled employs this token-based approach. This method of node authentication for communication is unique compared to other security measures offered by popular mainstream databases.

Moreover, token-based authentication can also be used when authenticating users, such as when Kibana communicates with Elasticsearch. You can use tokens instead of specifying username/password credentials in /etc/kibana/kibana.yml. 

However, based on my experience, this is a more advanced approach to security, and I recommend getting familiar with it. It’s fascinating how you can incorporate tokens to authenticate and allow Elasticsearch to manage these tokens through their internal API, ensuring secure login and communication attempts.

For detailed instructions on enrolling nodes in Elasticsearch or Kibana, refer to the official documentation.

6. Enable password protection

In the Elastic Stack, security features include built-in user credentials to help you get up and running. It is highly recommended that you familiarize yourself with these built-in users. For example, Elasticsearch includes the elastic user, while Kibana has the kibana_system user.

These users should be password-protected. Unlike the elastic user, which is automatically configured during installation, you may need to set or reset passwords for other users. If you need to reset the password for the elastic user, refer to our earlier discussion on this process.

Passwords should be updated regularly. It is best practice to change passwords at least every three months. Additionally, if personnel who have access to your Elasticsearch nodes and underlying servers change, make sure to update the passwords promptly to prevent any malicious intent.

7. User Authentication with LDAP or Active Directory

Many organizations utilize their existing authentication systems, such as LDAP or Active Directory, to authenticate users. The Elastic Stack features support communication with LDAP and Active Directory, allowing you to seamlessly integrate your security authentication with your Elasticsearch cluster.

Although this might seem complex initially, once it is set up, it ensures robust security and safeguards. Additionally, this integration means you don’t need to manage Elasticsearch security in a separate realm, streamlining your overall security infrastructure.

8. Limit the users by role

In Elasticsearch, built-in roles are provided that you can explicitly assign to users. By default, Elastic Stack security features roles for all users, including anonymous users. The default role allows users to access the authentication endpoint, change their own password, and obtain information about themselves.

Elasticsearch offers a Role-Based Access Control (RBAC) mechanism, which enables you to authorize users by assigning privileges to roles and then assigning those roles to users or groups. Using roles, you can assign security privileges limiting users’ functions when accessing Elasticsearch or the Elastic Stack itself. This ensures that users have only the necessary permissions for their tasks, enhancing overall security.

9. Keep it private

Keeping your Elasticsearch isolated from internet access significantly enhances security and safeguards against data breaches or intrusions with malicious intent. Ideally, security implementations for databases involve accessing them through a bastion host and a series of jump hosts. Others use VPNs or secure tunneling to access their servers, providing additional protection and complexity against intruders.

If exposing your Elasticsearch ports to the world is necessary, ensure you:

1. Use a port other than the default 9200.
2. Assign roles that limit user permissions and avoid anonymous access.
3. Implement Role-Based Access Control (RBAC) to effectively manage and restrict user access.

These measures will help maintain a secure Elasticsearch environment even when external access is required.

10. Enable audit logging

Although this security feature is not available to Elasticsearch’s free license users, enabling audit logging if you plan to subscribe to a license can significantly enhance your ability to trace and track audit trails, preventing potential damage or harm to your data. 

You can log security-related events such as authentication failures and refused connections to monitor your cluster for suspicious activity, including data access authorization and user security configuration changes.Audit logging also provides forensic evidence in the event of an attack. By default, this feature is disabled, but enabling it is straightforward. To enable audit logging, set the following parameter to true in your /etc/elasticsearch/elasticsearch.yml configuration file. Set the following parameter as below:

xpack.security.audit.enabled: true

Then restart Elasticsearch…

systemctl restart elasticsearch.service

11. Always backup your data

In case of data breaches or ransom attacks, it is crucial to always have backup data for safekeeping. Elasticsearch provides the capability to create backups through snapshots. This method is the most reliable and highly recommended by Elasticsearch for backing up and restoring your data when necessary.

Snapshots allow you to capture the state of your cluster at a specific point in time, including indices and their settings. To ensure data safety, regularly schedule snapshots and store them in a secure location. This practice will help you quickly recover from any data loss incidents.

12. Disabling security in Elasticsearch

While disabling security is not a best practice, there might be specific cases where you might consider it. However, this should be approached with caution, especially if you are dealing with confidential or sensitive data. 

Security should always be a priority and should be implemented with appropriate safeguards. That said, there are scenarios where data can be regenerated and does not pose a risk if publicly accessed. In such cases, prioritizing speed and simplicity over security might be acceptable, particularly for proof-of-concept demonstrations.

For example, you might temporarily disable security if you need to quickly showcase a proof-of-concept scenario to demonstrate how data is processed and the potential outcomes.

To disable security in Elasticsearch, you can deactivate the X-Pack security plugin by modifying your elasticsearch.yml configuration file and setting the following:

xpack.security.enabled: false

13. Allow anonymous access

Another aspect to consider is that Elasticsearch also handles anonymous incoming requests, meaning no authentication token can be extracted from the incoming request. By default, anonymous requests are rejected and returned with a status code 401.

To enable anonymous access, you assign one or more roles to anonymous users in the elasticsearch.yml configuration file. For example, the following configuration assigns anonymous users the roles role1 and role2:

xpack.security.authc:
  anonymous:
    username: anonymous_user 
    roles: role1, role2 
    authz_exception: true 

What do the following configuration settings for anonymous users in Elasticsearch mean:

• principal: The username/principal of the anonymous user. Defaults to _es_anonymous_user if not specified.
• roles: The roles to associate with the anonymous user. If no roles are specified, anonymous access is disabled, meaning anonymous requests will be rejected and return an authentication error.

• authz_exception: When set to true, a 403 HTTP status code is returned if the anonymous user does not have the necessary permissions to perform the requested action, and the user will not be prompted to provide credentials to access the requested resource. When set to false, a 401 HTTP status code is returned if the anonymous user does not have the necessary permissions, and the user is prompted for credentials to access the requested resource. If you are using anonymous access in combination with HTTP, you should set authz_exception to false if your client does not support pre-emptive basic authentication – defaults to true.

Using Clustercontrol with Elasticsearch automatic security

Clustercontrol deploys Elasticsearch with security enabled by default, making it the standard for any Elasticsearch cluster deployments. The difference between manually installing Elasticsearch with security autoconfiguration and using Clustercontrol is that the latter provides transport and client security in place, resulting in hassle-free and error-resistant configurations.

Certificates, including private and public certs, are generated, and the client certificate is stored in /var/lib/cmon/ca/elastic/cluster_CLUSTER_ID/https/kibana/elasticsearch-ca.pem. You can use this certificate to securely communicate from the client to any Elasticsearch node in the cluster.

Additionally, repository and backup configurations are automatically set up for you, eliminating the need for manual configuration. Once an Elasticsearch cluster is deployed fresh, you can create and schedule backups, which will be stored in the designated repository path specified during deployment.

Here’s an example of the designated repository path for reference:

Once your deployed cluster is set up, you can manage backups by navigating to the Backups tab. Here, you can perform various backup-related actions. Alternatively, you can create a backup and store it in any S3-compatible destination.

For example, to set up an S3-compatible backup destination, you might configure it as follows:

Wrapping up

Elasticsearch security is an ever-evolving, state-of-the-art implementation. This means it continually improves and adapts to meet the most demanding data protection and security requirements. You can explore subscription options under the Elastic Stack security group for enhanced security features.

When it comes to hardening the security of your hardware and environment, firewalls and safeguards are crucial, especially if you manage large amounts of confidential data. Without these protections, your data could be vulnerable to ransom attacks or leaks for profit, which you want to avoid.

Security should always be a top priority. Learning the basics of Elasticsearch security will provide essential protection against catastrophic outcomes. Investing in robust security measures and staying updated with the latest security practices will help ensure the safety and integrity of your data.

Follow us on LinkedIn and Twitter for more great content in the coming weeks. Stay tuned!