Set Elasticsearch built-in user passwords

The fix

# Reset the elastic superuser password (prints a new one)
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic

# Set passwords for the other built-in users interactively
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u kibana_system

Why it matters

Elasticsearch ships several built-in users, and one of them — elastic — is a superuser with complete control: every index, every setting, user management, and the ability to grant itself anything it doesn’t already have.

How its password starts depends on how the cluster came up:

• 8.x/9.x auto-configuration generates a random elastic password and prints it once, at first startup. If nobody captured it, it’s not lost — you reset it — but it does mean the password is often an unknown, which is its own problem.
• 7.x, or manual setup, starts with the built-in users effectively unusable until you run elasticsearch-setup-passwords, and clusters that were set up hastily sometimes have weak or shared passwords across all of them.

Either way, the elastic account is the keys to the cluster, and it should have a strong, known, and rarely used password.

Don’t use elastic for anything routine

This is the actual control, more than the password itself.

elastic is a superuser, and superusers should authenticate almost never — emergencies and initial setup. Every routine consumer should have its own credentials scoped to what it needs:

• Kibana uses the kibana_system service account, not elastic.
• Applications get an API key or a custom role, not elastic.
• Logstash and Beats get their own users with write access to their indices and nothing else.

An application configured with the elastic credentials means a compromise of that application is a compromise of the entire cluster — and it means the superuser password is sitting in an application config file, probably in more than one place. The least-privilege page covers what to give them instead.

The other built-in users

Beyond elastic, the built-in service accounts each have a specific job: kibana_system for Kibana’s own operations, logstash_system for monitoring, beats_system, remote_monitoring_user, and others. They are not for humans and not for applications — they exist so those components can function without a superuser.

Set passwords for the ones you use, and don’t repurpose them. kibana_system is scoped for Kibana’s needs; giving it to your app both over- and under-privileges the app.

Verify it worked

List the users that exist and which are enabled:

curl -sk -u elastic https://localhost:9200/_security/user?filter_path='*.username,*.roles,*.enabled'

Check which accounts have the superuser role — the list should be short and human:

curl -sk -u elastic https://localhost:9200/_security/user | \
  python3 -c 'import sys,json; [print(u) for u,d in json.load(sys.stdin).items() if "superuser" in d.get("roles",[])]'

Any application account with superuser is a finding.

Confirm the elastic password isn’t weak or default by testing a few obvious ones — each should fail:

for p in changeme elastic password; do
  printf '%-10s %s\n' "$p" "$(curl -sk -u "elastic:$p" https://localhost:9200/ -o /dev/null -w '%{http_code}')"
done

200 for any of those is an emergency.

See what’s authenticating as elastic right now — ideally nothing routine:

curl -sk -u elastic https://localhost:9200/_security/_authenticate     # who am I

Enable audit logging if you need to see which clients use elastic over time; without it, you’re inferring from application configs.

Before you apply this

Resetting a built-in user’s password breaks whatever was using it. The classic outage: reset kibana_system and Kibana stops connecting, because its config still has the old password. Update the consumer’s configuration in the same change.

elasticsearch-reset-password generates a new password by default and prints it — capture it. Use -i for an interactive prompt if you want to choose one:

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic -i

If you’re locked out entirely — nobody has the elastic password and every admin account is unusable — the reset tool is the way back in, because it runs locally on the node with filesystem access and doesn’t need an existing credential. That’s why the tool exists, and why filesystem access to an Elasticsearch node must be treated as equivalent to superuser: anyone who can run that binary can reset elastic and own the cluster.

Rotating elastic is safe precisely because nothing routine should use it. If rotating the superuser password breaks an application, that break has told you the application was using the superuser — fix that, then rotate. The pain is the diagnosis.

Don’t DELETE built-in users to “clean up” — they’re reserved and Elasticsearch depends on some of them. Disable ones you don’t need instead:

curl -sk -u elastic -X PUT https://localhost:9200/_security/user/logstash_system/_disable

Related

• API keys and least privilege — what applications should use instead of elastic.
• Enable security — creates these users in the first place.