Learn Elasticsearch - Security Fundamentals - Authentication & Authorization

#Introduction

An unsecured cluster is a server without a lock: anyone who can reach port 9200 can read, modify, even delete all data. Since Elasticsearch 8.0, security is enabled by default. Episode 15 covers the two pillars of security — authentication (identity verification) and authorization (what's allowed): enabling security, built-in users and realms, user and role management, authentication methods, and RBAC with DLS/FLS and role mapping.

#Enabling Security

Security is enabled in elasticsearch.yml. On 8.x, a fresh installation enables it automatically and prints the superuser elastic password. To verify or enable it manually:

xpack.security.enabled: true
xpack.security.enrollment.enabled: true
xpack.security.transport.ssl.enabled: true

If security has never been enabled, set passwords for the built-in users after startup:

bin/elasticsearch-setup-passwords auto

Don't forget to restart Kibana after enabling security, then log in with the elastic user and the newly generated password.

#Built-in Users and Realms

Elasticsearch ships with built-in users, each with a specific role:

These users use a realm (authentication source): the file realm stores users in a local file, the native realm in an internal index, and ldap/active_directory/saml/oidc connect to external systems. The realm order determines authentication priority — users in the native realm are the most common for everyday needs.

#User and Role Management

Users and roles are created via the Security API:

POST /_security/user/arman
{
  "password": "StrongPass2026!",
  "roles": ["kibana_admin", "viewer"],
  "full_name": "Arman Dwi Pangestu",
  "email": "arman@example.com"
}

Check user details with GET /_security/user/arman. A user can have many roles; different roles have their permissions summed. Never give the superuser role to an application user — grant the least privilege possible.

#Authentication Methods

#Native Realm (Internal Users)

#LDAP / Active Directory

For organizations that already have a directory server, AD/LDAP integration lets company users log in directly without duplicate users:

xpack.security.authc.realms.active_directory.my_ad:
  order: 2
  domain_name: corp.example.com
  url: ldap://dc1.corp.example.com
  bind_dn: cn=service-account,dc=corp,dc=example,dc=com

#SAML and OIDC

For browser-based single sign-on (company portals), SAML and OpenID Connect connect Elasticsearch/Kibana with an IdP such as Okta, Azure AD, or Keycloak. Good for UI access; API keys remain the primary choice for applications.

#API Keys

For application access, API keys are the gold standard — credentials that can be created per application, revoked without deleting a user, and scoped to limited permissions:

POST /_security/api_key
{
  "name": "search-app-key",
  "role_descriptors": {
    "search_only": {
      "indices": [
        { "names": ["produk*"], "privileges": ["read", "view_index_metadata"] }
      ]
    }
  }
}

The response returns an api_key (a secret value) that applications use as the Authorization: ApiKey <encoded> header. If a key leaks, revoke it with DELETE /_security/api_key.

#Service Tokens

For services that run continuously (like Beats or agents), service accounts provide tokens that are easier to rotate: POST /_security/service/{namespace}/{service}/credential/token.

#Authorization and RBAC

#Creating a Custom Role

PUT /_security/role/log_viewer
{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["logs-*"],
      "privileges": ["read", "view_index_metadata"]
    }
  ]
}

Index privileges control per-index access (read, write, delete, manage, etc.); cluster privileges control cluster-level access (monitor, manage, manage_ilm, etc.).

#Document and Field Level Security

Document Level Security (DLS) restricts which documents can be seen — for example, support users only see their own division's logs; Field Level Security (FLS) hides specific fields such as passwords or tokens:

{
  "indices": [
    {
      "names": ["produk"],
      "privileges": ["read"],
      "query": { "term": { "owner.keyword": "support-team" } },
      "field_security": { "grant": ["name", "price", "category"], "except": ["internal_note"] }
    }
  ]
}

#Role Mapping

Role mapping connects external identities (LDAP/AD groups or SAML attributes) to Elasticsearch roles:

PUT /_security/role_mapping/log_admin
{
  "roles": ["log_viewer", "kibana_admin"],
  "rules": {
    "field": {
      "groups": "cn=devops,ou=Groups,dc=corp,dc=example,dc=com"
    }
  }
}

With role mapping, access management follows the organizational structure — DevOps group members automatically have the same access, and membership rotation is managed in AD, not in Elasticsearch.

#Conclusion

In episode 15 you mastered security fundamentals: enabling xpack.security, built-in users and realms, user and role management, authentication methods (native, LDAP/AD, SAML, API keys, service tokens), and authorization with custom roles, index/cluster privileges, DLS/FLS, and role mapping.

Key takeaways:

• Security is enabled by default in 8.x — the elastic user is a superuser; keep it safe.
• A realm is the authentication source; AD/LDAP for humans, API keys for applications.
• API keys grant limited rights and can be revoked without deleting a user.
• RBAC uses index privileges and cluster privileges.
• DLS/FLS limits visible documents and fields — matching least privilege.
• Role mapping connects external groups to Elasticsearch roles.

Authentication and authorization are working, but there's one more layer: protecting data in transit and securing the network. In episode 16 we'll cover network security and encryption: TLS for the HTTP and transport layers, certificate creation and renewal, bind/publish addresses, and firewalls and network isolation in the cloud. See you there!