WARNING: Version 5.6 of the Elastic Stack has passed its EOL date.

This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.

« How Security Works How Authentication Works »

› ›

Setting Up User Authentication

edit

Setting Up User Authentication

edit

Authentication identifies an individual. To gain access to restricted resources, a user must prove their identity, via passwords, credentials, or some other means (typically referred to as authentication tokens).

You can use the native support for managing and authenticating users, or integrate with external user management systems such as LDAP and Active Directory. For information about managing native users, see Managing Native Users.

Built-in Users

edit

X-Pack security provides built-in user credentials to help you get up and running. These users have a fixed set of privileges and the default password changeme. Please read Reset Built-in User Passwords and Disable Default Password Functionality below.

Table 3. X-Pack security Built-in Users

Name	Description
`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.

How the Built-in Users Work

edit

These built-in users are stored within a special .security index managed by X-Pack 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. Disabling the native realm will not have any effect on the built-in users. The built-in users can be disabled individually, using the user management API.

Reset Built-in User Passwords

edit

You must reset the default passwords for all built-in users, and then disable default password support. You can update passwords from the Management > Users UI in Kibana or with the Reset Password API:

PUT _xpack/security/user/elastic/_password
{
  "password": "elasticpassword"
}

PUT _xpack/security/user/kibana/_password
{
  "password": "kibanapassword"
}

PUT _xpack/security/user/logstash_system/_password
{
  "password": "logstashpassword"
}

Once the kibana user password is reset, you need to update the Kibana server with the new password by setting elasticsearch.password in the kibana.yml configuration file:

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:

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:

PUT _xpack/security/user/logstash_system/_enable

Disable Default Password Functionality

edit

The default password of changeme is provided as a convenience that allows you to quickly setup your Elasticsearch stack. It should not be used when running in production.

Once you have changed the password for the built-in users, you should disable default password support by setting xpack.security.authc.accept_default_password to false.

Internal Users

edit

X-Pack security has three internal users (_system, _xpack, and _xpack_security) that are responsible for the operations that take place inside an Elasticsearch cluster.

These users are only used by requests that originate from within the cluster. For this reason, they cannot be used to authenticate against the API and there is no password to manage or reset.

From time-to-time you may find a reference to one of these users inside your logs, including audit logs.

« How Security Works How Authentication Works »