Enable Elasticsearch security

The fix/etc/elasticsearch/elasticsearch.yml

xpack.security.enabled: true

sudo systemctl restart elasticsearch

On 8.x and 9.x this is already true — the finding is when it’s been set to false. On 7.x it defaults to absent, which means off.

Why it matters

With security disabled, Elasticsearch has no concept of a user. Every request to port 9200 is honoured in full: read every index, delete every index, read the cluster’s configuration, and — historically — run code. There is no password to guess because there is no password.

This is the setting that made Elasticsearch the most breached database on the internet for years. A cluster with xpack.security.enabled: false reachable from an untrusted network is not at risk of compromise; it is compromised the moment someone connects.

The two situations

On 8.x and 9.x, someone turned it off. Auto-configuration enables security on first start, so a modern cluster running insecure got that way deliberately. The reason is almost always the same: a client failed to connect — usually because it wasn’t sending credentials or wasn’t trusting the auto-generated certificate — and xpack.security.enabled: false made the error stop.

That “fix” trades an authentication error for an open database. The real fix is to make the client authenticate and trust the certificate, which is built-in users and TLS — not turning the wall off.

On 7.x, it was never on. Elasticsearch 7.x ships with security disabled by default. If nobody added xpack.security.enabled: true, the cluster is open, and has been since it was installed. 7.x is also end of life, so the durable fix is to enable security and plan the upgrade — an unsupported version accumulates unpatched holes regardless of this setting.

Free since 2019

If the reason security is off is a belief that it costs money: it doesn’t, and hasn’t since 2019. Authentication, RBAC and TLS are in the free Basic tier from 6.8 / 7.1 onward. The only thing on this whole checklist that needs a paid subscription is audit logging.

Enabling it requires no license key and no registration.

Verify it worked

Ask the cluster whether security is active. The tell is whether an unauthenticated request is refused:

curl -s -o /dev/null -w '%{http_code}\n' http://localhost:9200/

200 means security is off — the cluster answered a request with no credentials. 401 means it’s on and demanding authentication.

Confirm against the settings:

curl -sk -u elastic https://localhost:9200/_cluster/settings?include_defaults=true \
  | grep -o '"enabled":[a-z]*' | head
grep xpack.security.enabled /etc/elasticsearch/elasticsearch.yml

And prove authentication actually works once on:

curl -sk -u elastic:WRONG https://localhost:9200/ -o /dev/null -w '%{http_code}\n'   # expect 401
curl -sk -u elastic https://localhost:9200/ -o /dev/null -w '%{http_code}\n'         # prompts; expect 200

Note the scheme flips from http to https when security auto-configures TLS — a curl http:// that suddenly fails is often just that.

Before you apply this

Enabling security breaks every client that isn’t sending credentials — which, if security has been off, is all of them. It also turns on TLS in the 8.x/9.x auto-configuration path, so clients using http:// need to move to https:// and trust the certificate at the same time.

This is a bigger change than a single setting, and doing it under pressure is how people end up setting it back to false. Stage it:

1. Enable security and restart. The cluster comes up secured, clients start failing — expected.
2. Retrieve the elastic password and set passwords for the built-in users — see built-in users. On a restart of an already-configured node, the password isn’t reprinted; reset it with elasticsearch-reset-password.
3. Give each application its own credentials — an API key or role, not the elastic superuser.
4. Update clients to authenticate and to use https:// with the CA certificate, then confirm each connects.

Do this in a maintenance window. Every consumer — Logstash, Beats, Kibana, your application, every dashboard — needs credentials before it works again.

On a multi-node cluster, enabling security also requires transport TLS between nodes, or the nodes can’t form a cluster. That’s not optional and it’s not a client problem — see TLS. Enabling security on one node while the others are open, or without transport TLS configured, breaks cluster formation rather than securing it.

Related

• Built-in users and passwords — the accounts this creates.
• Enable TLS — the other half of the auto-configuration.
• Elasticsearch exposed to the internet — what off means.