Elasticsearch security hardening (security, TLS, roles, audit)

Not an installation or day-to-day operations guide: a scenario-based runbook for hardening a running Elasticsearch cluster. Read-only security audit, enabling disabled security together with transport TLS (full cluster restart), rolling migration to HTTP TLS, DBA/application roles, API keys with expiration, an emergency file realm user, taking elastic out of daily use, disabling anonymous access, network.host and IP filtering, audit logging (with a license check), snapshot repository access and the Kibana service account token; at the end the audit is repeated to show that the risks are closed. On 8.x/9.x RPM/DEB installations security and TLS are already enabled: start with the audit and apply only the scenarios that report RISK or WARNING. Shard, disk and node tasks are in the operations guide, backups in the snapshot guide.

Topology: Elasticsearch cluster with 1–12 nodes (+ Kibana)

Scenarios

• Security status audit (read-only) — Changes nothing. Whether security is enabled, unauthenticated access, HTTP/transport TLS, anonymous access, users and use of elastic, API keys without expiration, audit logging, IP filtering, listening addresses and license status are reported as OK / WARNING / RISK. Choose this if you do not know where to start.
• Full hardening (all in order) — Audit → security + transport/HTTP TLS (if disabled; full cluster restart) → users/roles/API keys, disabling anonymous, taking elastic out of daily use → network and IP filtering → audit logging (if the license allows) → snapshot repository access → Kibana connection → final audit.
• Security disabled: enable security and transport TLS — A cluster with xpack.security.enabled: false, or upgraded from 7.x, that is accessed without authentication. Certificates are generated and security is enabled with transport (and optionally HTTP) TLS. A full cluster restart is required (outage): TLS and non-TLS connections between nodes cannot coexist.
• Move HTTP (REST) traffic to TLS — Security is enabled but port 9200 is plain HTTP: passwords can be read on the network. HTTP certificates are distributed and the nodes are restarted one by one; clients move to https://.
• Users, roles, API keys; elastic and anonymous access — Applications connect with the elastic superuser, anonymous access is enabled, or there are API keys without expiration. Separate roles/users for DBAs and applications, an API key with expiration for the application, an emergency (file realm) user; the elastic password is changed and elastic is taken out of daily use.
• Enable audit logging — Who accessed which index, failed login attempts, authorization denials and security setting changes must be recorded. xpack.security.audit.enabled (static, rolling restart) — requires a license (the step checks the license).
• Network access and IP filtering — 9200/9300 listen on all interfaces or are open to everyone. network.host is reduced to the internal IP, and with the firewall and Elasticsearch IP filtering only the nodes, Kibana and the application network are allowed.
• Secure snapshot repository access — The snapshot directory is world-readable, the privilege to manage the repository is broad, or cloud access keys are in elasticsearch.yml. Directory permissions, a snapshot operator role, the keystore and a read-only repository registration on the second cluster.
• Secure the Kibana connection — Kibana connects with the elastic user or without encryption, and the password is in plain text in kibana.yml. Service account token, CA verification, keystore and encryption keys.

Before you start

• root/sudo on all nodes; SSH from the first node to the others (certificate distribution).
• The cluster is green; rolling operations are not performed on an unhealthy cluster.
• python3 (JSON parsing), openssl and unzip are installed.
• Enabling security (transport TLS) requires a full cluster restart: a maintenance window and a snapshot taken beforehand.
• Client inventory (Kibana, Logstash, Beats, applications): once HTTP TLS and authentication are enabled, each of them must be updated with https + CA + user/API key.
• Audit logging and IP filtering are paid license features (Gold and above: Gold, Platinum, Enterprise or a 30-day trial; for new self-managed subscriptions Platinum/Enterprise). Neither works with a Basic license: the setting is accepted, but no audit records are produced and the IP filter blocks no connection. License: GET _license.

Phases of the guide

• Preparation: safety net and helper tools — Configuration, keystore and certificate backup: … · Take a snapshot (recommended) · PyYAML and tools: … · Configuration file permissions: … · Write the admin credentials to the netrc file
• Status audit (read-only) — Security report: … · Map the findings to scenarios
• Enable security: diagnosis and certificates — Diagnosis: is security really disabled? · Generate the CA and node certificates · Distribute the certificates to the nodes · Certificate permissions: … · elasticsearch.yml: security and TLS settings: … · Stop shard allocation and flush
• Enable security: full cluster restart — Stop: … · Start: … · Set the elastic password · Write the admin credentials to the netrc file (elastic) · Re-enable shard allocation and wait for health · kibana_system password …
• HTTP TLS: certificates — Current state · Generate the HTTP certificates · Distribute and set permissions: …
• Users, roles and API keys — Existing users, roles and API keys · DBA admin user (…) · Emergency user (file realm): … · Application role and user (…) · API key with expiration for the application · Verify least privilege (…) …
• Network access and IP filtering — Firewall: … · Is network.host on the internal IP: … · Elasticsearch IP filtering
• Audit logging: license and settings — Does the license allow audit logging?
• Audit logging: event selection and verification — Which events to record · Are audit records produced: …
• Snapshot repository access — Snapshot directory permissions: … · Repository list, cloud keys and snapshot operator role
• Kibana connection — Kibana service account token · kibana.yml and keystore · Verify the Kibana connection
• Final audit (after hardening) — Security report: … (final state)
• Cleanup and follow-up — Delete the temporary credential files: … · Follow-up