How to reset built-in user passwords in Elasticsearch

Rotating built-in Elasticsearch passwords limits the time that leaked credentials remain useful and helps restore control quickly after staff changes, secret exposure, or component migrations. Reserved accounts such as elastic and kibana_system already exist on secured clusters, so keeping their passwords current is part of normal cluster hygiene.

Built-in users are reserved accounts stored in the security index rather than in the native user list. On self-managed clusters, the elasticsearch-reset-password utility reads the local node's security and HTTP TLS settings from /etc/elasticsearch/elasticsearch.yml and resets the target built-in user's password. By default it generates a strong password automatically, but it can also prompt for an explicit password with -i.

This workflow is for self-managed clusters with command-line access to an Elasticsearch node. Current releases create a temporary file-realm user behind the scenes, so the tool cannot run when the file realm is disabled. On package installs, the HTTP API is usually protected by HTTPS on port 9200 and the local CA certificate is typically /etc/elasticsearch/certs/http_ca.crt, so validation commands should use that CA file unless the cluster was reconfigured.

1. Identify the reserved account that needs rotation.

   Common built-in users include elastic, kibana_system, logstash_system, beats_system, apm_system, and remote_monitoring_user. The elastic user is a superuser, while the service users are meant for Elastic components rather than interactive human sign-in.

2. Run the password reset tool on an Elasticsearch node for the target built-in user.

   $ sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic
   This tool will reset the password of the [elastic] user to an autogenerated value.
   The password will be printed in the console.
   Please confirm that you would like to continue [y/N] y
   
   Password for the [elastic] user successfully reset.
   New value: V8fC7wqNn2rT4xYpL6mH

   Use -i to enter a specific password instead of generating one, and add -b when the confirmation prompt must be suppressed for automation. If the node uses a non-default config directory, run the tool with the correct ES_PATH_CONF value so it can read the local TLS settings. Use –url when the local node is not reachable on the default endpoint.

   The utility creates a temporary file-realm user to submit the password-change request. If the file realm is disabled in /etc/elasticsearch/elasticsearch.yml or a custom config path, use Kibana or the password-change API instead.

3. Save the new secret immediately and update every service or client that authenticates with that account.

   Rotating kibana_system, logstash_system, beats_system, apm_system, or remote_monitoring_user without updating their stored credentials can break monitoring, ingestion, or Kibana background tasks until the new password is applied.

4. Verify that the new password can authenticate to the secured HTTP API.

   $ curl -sS --cacert /etc/elasticsearch/certs/http_ca.crt \
     -u elastic https://localhost:9200/_security/_authenticate?pretty
   Enter host password for user 'elastic':
   {
     "username" : "elastic",
     "roles" : [
       "superuser"
     ],
     "full_name" : null,
     "email" : null,
     "metadata" : {
       "_reserved" : true
     },
     "enabled" : true,
     "authentication_realm" : {
       "name" : "reserved",
       "type" : "reserved"
     },
     "lookup_realm" : {
       "name" : "reserved",
       "type" : "reserved"
     },
     "authentication_type" : "realm"
   }

   A successful response confirms both the new credential and the HTTPS trust path. When the cluster uses a different CA file, replace the CA path. If HTTP TLS was intentionally disabled, switch the URL to http://localhost:9200 and drop –cacert.

5. Reset additional built-in users with the same command pattern when their stored secrets also need rotation.

   $ sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u kibana_system -i

   Interactive mode is useful for component accounts whose password must be copied directly into a keystore, secret manager, or configuration management system.