Elasticsearch Security Review

Elasticsearch listens for client requests on port 9200 and for inter-node traffic on port 9300. Elastic’s own documentation states a node binds only to localhost by default, but changing network.host to reach it from another machine exposes both ports to whatever network can route to them.

Why Elasticsearch security depends on what was configured, and when

Elastic’s documentation on automatic security setup states that since version 8.0, Elasticsearch automatically enables security features on first startup, but only when the node is not already part of an existing cluster and none of a defined list of settings has been configured beforehand. That condition matters more than the version number: a node upgraded from an older release, restored from a snapshot, or started with one incompatible setting already in elasticsearch.yml never goes through the automatic step, so how a cluster reached its current state decides more than which version it runs today. Anonymous access follows a similar shape. Elastic’s anonymous access documentation confirms that requests carrying no authentication token are rejected with a 401 by default, and stay that way unless a role is explicitly assigned to the anonymous user in elasticsearch.yml.

Role definitions carry document and field-level security in the same block as ordinary index privileges, and Elastic is explicit that omitting the query parameter entirely disables document level security for that permission entry, rather than falling back to a safe restriction. Field-level security sits alongside it as a grant and except list of field names on the same role, and Elastic warns it should never be set on an alias field, since securing a concrete field means naming that field directly; a multi-field variant such as a .raw suffix is stored independently and is not excluded automatically when its parent field is. API keys carry their own scope through role descriptors set at creation, and a key created through the full options screen does not expire by default, unlike the quick personal key from Kibana’s Help menu, which is given a 90-day expiry automatically.

Kibana privileges are assigned per space rather than cluster-wide: a role’s base or feature privileges only reach the spaces named alongside them, and Elastic’s spaces documentation confirms each space holds its own saved objects, with users limited to the spaces they have actually been granted. Snapshot repositories add a further privilege list of their own, since Elastic’s prerequisites for Kibana’s Snapshot and Restore feature require the monitor, manage_slm, cluster:admin/snapshot and cluster:admin/repository cluster privileges together, with a separate cluster:admin/settings/update privilege needed only to change which repository is the default. None of this changes much between self-managed and Elastic Cloud: Elastic Cloud automatically secures inter-node and HTTPS traffic and encrypts data at rest, but the roles, API keys, document queries and field grants you configure are the same access model either way. For the wider family of cache and streaming platforms this scope splits from, see our NoSQL, cache and streaming security review. OpenSearch, an open-source fork of an older Elasticsearch codebase now run under the Linux Foundation, has since diverged into its own access-control model and gets its own scope and page.