204 lines
8.8 KiB
Plaintext
204 lines
8.8 KiB
Plaintext
[role="xpack"]
|
|
[[built-in-users]]
|
|
=== Built-in users
|
|
|
|
The {stack-security-features} provide 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.
|
|
`apm_system`:: The user the APM server uses when storing monitoring information in {es}.
|
|
`remote_monitoring_user`:: The user {metricbeat} uses when collecting and
|
|
storing monitoring information in {es}. It has the `remote_monitoring_agent` and
|
|
`remote_monitoring_collector` built-in roles.
|
|
|
|
|
|
[float]
|
|
[[built-in-user-explanation]]
|
|
==== How the built-in users work
|
|
These built-in users are stored in a special `.security` index, which is managed
|
|
by {es}. If a built-in user is disabled or its password
|
|
changes, the change is automatically reflected on each node in the cluster. If
|
|
your `.security` index is deleted or restored from a snapshot, however, any
|
|
changes you have applied are 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-disable-user.html[disable users 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`, `beats_system`, `apm_system`,
|
|
and `remote_monitoring_user` 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.
|
|
|
|
[[add-built-in-user-passwords]]
|
|
|
|
[float]
|
|
[[add-built-in-user-kibana]]
|
|
==== Adding built-in user passwords to {kib}
|
|
|
|
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
|
|
-----------------------------------------------
|
|
|
|
See {kibana-ref}/using-kibana-with-security.html[Configuring security in {kib}].
|
|
|
|
[float]
|
|
[[add-built-in-user-logstash]]
|
|
==== Adding built-in user passwords to {ls}
|
|
|
|
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,
|
|
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,console]
|
|
---------------------------------------------------------------------
|
|
PUT _security/user/logstash_system/_enable
|
|
---------------------------------------------------------------------
|
|
|
|
See {logstash-ref}/ls-security.html#ls-monitoring-user[Configuring credentials for {ls} monitoring].
|
|
|
|
[float]
|
|
[[add-built-in-user-beats]]
|
|
==== Adding built-in user passwords to Beats
|
|
|
|
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
|
|
----------------------------------------------------------
|
|
|
|
For example, see {metricbeat-ref}/monitoring.html[Monitoring {metricbeat}].
|
|
|
|
The `remote_monitoring_user` is used when {metricbeat} collects and stores
|
|
monitoring data for the {stack}. See <<monitoring-production>>.
|
|
|
|
If you have upgraded from an older version of {es}, then you may not have set a
|
|
password for the `beats_system` or `remote_monitoring_user` users. 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 these users.
|
|
|
|
[float]
|
|
[[add-built-in-user-apm]]
|
|
==== Adding built-in user passwords to APM
|
|
|
|
The `apm_system` user is used internally within APM when monitoring is enabled.
|
|
|
|
To enable this feature in APM, you need to update the
|
|
{apm-server-ref-70}/configuring-howto-apm-server.html[APM configuration file] to
|
|
reference the correct username and password. For example:
|
|
|
|
[source,yaml]
|
|
----------------------------------------------------------
|
|
xpack.monitoring.elasticsearch.username: apm_system
|
|
xpack.monitoring.elasticsearch.password: apmserverpassword
|
|
----------------------------------------------------------
|
|
|
|
See {apm-server-ref-70}/monitoring.html[Monitoring APM Server].
|
|
|
|
If you have upgraded from an older version of {es}, then you may not have set a
|
|
password for the `apm_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 these users.
|
|
|
|
[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>>.
|
|
=============================================================================
|