Authentication and TLS in Elasticsearch
Elasticsearch security is enabled by default since version 8.0, meaning a fresh cluster requires TLS for transport and HTTP layers and forces you to set a password for the built-in elastic superuser during setup. Authentication can rely on the native realm (usernames and passwords stored in a dedicated security index), or be delegated to external identity providers through the SAML, OIDC, Kerberos, or LDAP/Active Directory realms configured in elasticsearch.yml. Every node-to-node request in the transport layer is also encrypted and mutually authenticated with certificates, which prevents an unauthorized process from joining the cluster and reading shard data directly.
Cricket analogy: This is like the ICC requiring every player entering the dressing room to badge in with an accredited pass, similar to how every Elasticsearch node must present a valid certificate before it's allowed to join the cluster's private conversation.
Role-Based Access Control (RBAC)
Elasticsearch RBAC is built around roles that combine cluster privileges (like monitor or manage_ilm), index privileges (like read or write scoped to an index pattern), and optionally field-level and document-level security. A role can restrict a user to reading only the customer_id and status fields of an index via field-level security, or only documents where region equals "EU" via a document-level security query, letting one shared index serve multiple tenants safely. Users are then assigned one or more roles, either directly in the native realm or mapped from external identity provider groups via role mapping rules.
Cricket analogy: This is like a broadcaster giving a commentary team access to raw Hawk-Eye data but restricting a rival team's analyst to only publicly released highlights — same data source, different privilege scope per role.
API Keys and Service Accounts
For machine-to-machine access, Elasticsearch supports API keys created via POST /_security/api_key, which return an id and an unencrypted secret shown only once and can be scoped to a subset of the creating user's privileges with an optional expiration time. This is preferred over embedding a username and password in application config, since an individual API key can be revoked without rotating a shared account's credentials, and each key's usage is separately auditable. Built-in service accounts, such as the one used by Kibana's server process (elastic/kibana), come with predefined minimal privileges rather than superuser access, following least-privilege by default.
Cricket analogy: An API key is like a match-day access card issued to a specific broadcast van for one series only, so if that van's card is lost it can be deactivated without changing every crew member's credentials.
PUT /_security/role/eu_support_readonly
{
"indices": [
{
"names": ["customers-*"],
"privileges": ["read"],
"field_security": { "grant": ["customer_id", "status", "region"] },
"query": "{ \"term\": { \"region\": \"EU\" } }"
}
]
}Since Elasticsearch 8.0, security features (TLS, authentication) are enabled automatically on a fresh install — you no longer need to explicitly turn on xpack.security.enabled, which reduces the risk of accidentally running an open cluster.
Never reuse the built-in elastic superuser for application connections. It bypasses all role restrictions, so a leaked credential or an application bug grants full cluster access — always create scoped roles and API keys per application instead.
- Security is enabled by default since Elasticsearch 8.0, enforcing TLS and authentication out of the box.
- Authentication realms include native, LDAP/AD, SAML, OIDC, and Kerberos.
- RBAC combines cluster privileges, index privileges, field-level security, and document-level security into roles.
- Document-level security queries let one index safely serve multiple tenants or regions.
- API keys provide scoped, revocable, auditable machine-to-machine credentials.
- Built-in service accounts like Kibana's follow least-privilege rather than superuser access.
- Never use the elastic superuser account for routine application connections.
Practice what you learned
1. Since which major version does Elasticsearch enable security features by default on a fresh install?
2. What does document-level security allow a role to do?
3. Why are API keys generally preferred over embedding username/password credentials in an application?
4. What is the recommended practice regarding the built-in elastic superuser account?
Was this page helpful?
You May Also Like
Elasticsearch with Kibana
How Kibana pairs with Elasticsearch as the visualization, exploration, and management layer of the Elastic Stack.
Elasticsearch Quick Reference
A condensed cheat sheet of core Elasticsearch REST API endpoints, Query DSL patterns, and cluster commands for daily use.
Elasticsearch Interview Questions
Commonly asked Elasticsearch interview topics covering architecture, indexing internals, and querying, with worked explanations.