157 lines
6.9 KiB
Plaintext
157 lines
6.9 KiB
Plaintext
|
[[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
|
||
|
<<set-built-in-user-passwords,set all of the built-in user passwords>>.
|
||
|
|
||
|
`elastic`:: A built-in _superuser_. See <<built-in-roles>>.
|
||
|
`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 <<native-realm, native realm>>. 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 <<set-built-in-user-passwords,set passwords for the built-in users>>,
|
||
|
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 <<bootstrap-elastic-passwords>>.
|
||
|
=============================================================================
|