[[built-in-users]] === Built-in users {security} provides built-in user credentials to help you get up and running. These users have a fixed set of privileges and cannot be authenticated until their passwords have been set. The `elastic` user can be used to <>. `elastic`:: A built-in _superuser_. See <>. `kibana`:: The user Kibana uses to connect and communicate with Elasticsearch. `logstash_system`:: The user Logstash uses when storing monitoring information in Elasticsearch. `beats_system`:: The user the Beats use when storing monitoring information in Elasticsearch. [float] [[built-in-user-explanation]] ==== How the built-in users work These built-in users are stored within a special `.security` index managed by {security}. This means that, if the password is changed, or a user is disabled, then that change is automatically reflected on each node in the cluster. It also means that if your `.security` index is deleted, or restored from a snapshot, then any changes you have applied will be lost. Although they share the same API, the built-in users are separate and distinct from users managed by the <>. Disabling the native realm will not have any effect on the built-in users. The built-in users can be disabled individually, using the {ref}/security-api-users.html[user management API]. [float] [[bootstrap-elastic-passwords]] ==== The Elastic bootstrap password When you install {es}, if the `elastic` user does not already have a password, it uses a default bootstrap password. The bootstrap password is a transient password that enables you to run the tools that set all the built-in user passwords. By default, the bootstrap password is derived from a randomized `keystore.seed` setting, which is added to the keystore during installation. You do not need to know or change this bootstrap password. If you have defined a `bootstrap.password` setting in the keystore, however, that value is used instead. For more information about interacting with the keystore, see {ref}/secure-settings.html[Secure Settings]. NOTE: After you <>, in particular for the `elastic` user, there is no further use for the bootstrap password. [float] [[set-built-in-user-passwords]] ==== Setting built-in user passwords You must set the passwords for all built-in users. The +elasticsearch-setup-passwords+ tool is the simplest method to set the built-in users' passwords for the first time. It uses the `elastic` user's bootstrap password to run user management API requests. For example, you can run the command in an "interactive" mode, which prompts you to enter new passwords for the `elastic`, `kibana`, `logstash_system`, and `beats_system` users: [source,shell] -------------------------------------------------- bin/elasticsearch-setup-passwords interactive -------------------------------------------------- For more information about the command options, see {ref}/setup-passwords.html[elasticsearch-setup-passwords]. IMPORTANT: After you set a password for the `elastic` user, the bootstrap password is no longer valid; you cannot run the `elasticsearch-setup-passwords` command a second time. Alternatively, you can set the initial passwords for the built-in users by using the *Management > Users* page in {kib} or the {ref}/security-api-change-password.html[Change Password API]. These methods are more complex. You must supply the `elastic` user and its bootstrap password to log into {kib} or run the API. This requirement means that you cannot use the default bootstrap password that is derived from the `keystore.seed` setting. Instead, you must explicitly set a `bootstrap.password` setting in the keystore before you start {es}. For example, the following command prompts you to enter a new bootstrap password: [source,shell] ---------------------------------------------------- bin/elasticsearch-keystore add "bootstrap.password" ---------------------------------------------------- You can then start {es} and {kib} and use the `elastic` user and bootstrap password to log into {kib} and change the passwords. Alternatively, you can submit Change Password API requests for each built-in user. These methods are better suited for changing your passwords after the initial setup is complete, since at that point the bootstrap password is no longer required. [float] [[add-built-in-user-passwords]] ==== Adding Built-in User Passwords To {kib}, Logstash, and Beats After the `kibana` user password is set, you need to update the {kib} server with the new password by setting `elasticsearch.password` in the `kibana.yml` configuration file: [source,yaml] ----------------------------------------------- elasticsearch.password: kibanapassword ----------------------------------------------- The `logstash_system` user is used internally within Logstash when monitoring is enabled for Logstash. To enable this feature in Logstash, you need to update the Logstash configuration with the new password by setting `xpack.monitoring.elasticsearch.password` in the `logstash.yml` configuration file: [source,yaml] ---------------------------------------------------------- xpack.monitoring.elasticsearch.password: logstashpassword ---------------------------------------------------------- If you have upgraded from an older version of elasticsearch/x-pack, the `logstash_system` user may have defaulted to _disabled_ for security reasons. Once the password has been changed, you can enable the user via the following API call: [source,js] --------------------------------------------------------------------- PUT _xpack/security/user/logstash_system/_enable --------------------------------------------------------------------- // CONSOLE The `beats_system` user is used internally within Beats when monitoring is enabled for Beats. To enable this feature in Beats, you need to update the configuration for each of your beats to reference the correct username and password. For example: [source,yaml] ---------------------------------------------------------- xpack.monitoring.elasticsearch.username: beats_system xpack.monitoring.elasticsearch.password: beatspassword ---------------------------------------------------------- If you have upgraded from an older version of {es}, then you may not have set a password for the `beats_system` user. If this is the case, then you should use the *Management > Users* page in {kib} or the {ref}/security-api-change-password.html[Change Password API] to set a password for this user. [float] [[disabling-default-password]] ==== Disabling default password functionality [IMPORTANT] ============================================================================= This setting is deprecated. The elastic user no longer has a default password. The password must be set before the user can be used. See <>. =============================================================================