Loading

Automatic security setup

Self Managed

When you start your first Elasticsearch node for the first time, it automatically performs the following security setup:

  • Generates TLS certificates for the transport and HTTP layers
  • Applies TLS configuration settings to elasticsearch.yml
  • Sets a password for the elastic superuser
  • Creates an enrollment token to securely connect Kibana to Elasticsearch

You can then start Kibana and enter the enrollment token, which is valid for 30 minutes. This token automatically applies the security settings from your Elasticsearch cluster, authenticates to Elasticsearch with the built-in kibana service account, and writes the security configuration to kibana.yml.

Note

There are some cases where security can’t be configured automatically because the node startup process detects that the node is already part of a cluster, or that security is already configured or explicitly disabled.

Note

In Elasticsearch RPM and Debian package installations, the elastic user password is not output at startup and must be manually reset.

To learn how to start Elasticsearch and Kibana with security enabled, follow one of our installation guides. Select the product that you want to install, and then select the guide your preferred installation method:

When you install Elasticsearch, the following certificates and keys are generated in the Elasticsearch configuration directory. These files are used to connect a Kibana instance to your secured Elasticsearch cluster and to encrypt internode communication. The files are listed here for reference.

http_ca.crt
The CA certificate that is used to sign the certificates for the HTTP layer of this Elasticsearch cluster.
http.p12
Keystore that contains the key and certificate for the HTTP layer for this node.
transport.p12
Keystore that contains the key and certificate for the transport layer for all the nodes in your cluster.

http.p12 and transport.p12 are password-protected PKCS#12 keystores. Elasticsearch stores the passwords for these keystores as secure settings. To retrieve the passwords so that you can inspect or change the keystore contents, use the bin/elasticsearch-keystore tool.

Use the following command to retrieve the password for http.p12:

bin/elasticsearch-keystore show xpack.security.http.ssl.keystore.secure_password

Use the following command to retrieve the password for transport.p12:

bin/elasticsearch-keystore show xpack.security.transport.ssl.keystore.secure_password

When you start Elasticsearch for the first time, the node startup process tries to automatically configure security for you. The process runs some checks to determine:

  • If this is the first time that the node is starting
  • Whether security is already configured
  • If the startup process can modify the node configuration

If any of those checks fail, there’s a good indication that you manually configured security, or don’t want security to be configured automatically. In these cases, the node starts normally using the existing configuration.

Important

If you redirect Elasticsearch output to a file, security autoconfiguration is skipped. Autoconfigured credentials can only be viewed on the terminal the first time you start Elasticsearch. If you need to redirect output to a file, start Elasticsearch without redirection the first time and use redirection on all subsequent starts.

If certain directories already exist, there’s a strong indication that the node was started previously. Similarly, if certain files don’t exist, or we can’t read or write to specific files or directories, then we’re likely not running as the user who installed Elasticsearch or an administrator imposed restrictions. If any of the following environment checks are true, security isn’t configured automatically.

The Elasticsearch /data directory exists and isn’t empty
The existence of this directory is a strong indicator that the node was started previously, and might already be part of a cluster.
The elasticsearch.yml file doesn’t exist (or isn’t readable), or the elasticsearch.keystore isn’t readable
If either of these files aren’t readable, we can’t determine whether Elasticsearch security features are already enabled. This state can also indicate that the node startup process isn’t running as a user with sufficient privileges to modify the node configuration.
The Elasticsearch configuration directory isn’t writable
This state likely indicates that an administrator made this directory read-only, or that the user who is starting Elasticsearch is not the user that installed Elasticsearch.

The following settings are incompatible with security auto configuration. If any of these settings exist, the node startup process skips configuring security automatically and the node starts normally.