Learn Elasticsearch - Network Security & Encryption

#Introduction

Episode 15 secured who is allowed in. Episode 16 secures the data itself as it travels across the network. Without encryption, everything sent — including passwords and API keys — can be intercepted mid-flight by anyone on the same network path.

Elasticsearch has two communication paths that must be secured: the HTTP layer (client interaction like curl, Kibana, applications) and the transport layer (inter-node communication inside the cluster). Episode 16 covers both, certificate creation and renewal, bind/publish address configuration, and network isolation at the firewall and cloud level.

#TLS and Certificate Concepts

TLS (Transport Layer Security) protects data in transit through encryption. It works with digital certificates: the server proves its identity (server authentication), and the client can verify that the connection really goes to the correct server. In Elasticsearch, there are three kinds of certificates:

• CA (Certificate Authority) — the "issuer" that signs other certificates. The trust at the root of the entire trust chain.
• Node certificate — a per-node certificate for the transport layer, signed by a CA.
• Client certificate — optional, for two-way authentication (mutual TLS).

#TLS for the HTTP Layer

The HTTP layer is the client gateway — Kibana, applications, curl. Everything must go through HTTPS. Configuration in elasticsearch.yml:

xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: elastic-certificates.p12
xpack.security.http.ssl.keystore.password: change-me

Once enabled, all HTTP access requires https://:

curl -k -u elastic:password https://localhost:9200/_cluster/health

-k disables certificate verification — only for quick tests. In real applications, you must use a CA trusted by the client so verification stays active.

#TLS for the Transport Layer

The transport layer is the inter-node path. Without encryption here, an intruder node could join and steal data from the inside. Configuration in elasticsearch.yml:

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

verification_mode: certificate verifies that the peer node holds a certificate signed by a trusted CA — without requiring hostname matching. This is mandatory to prevent man-in-the-middle attacks between nodes.

#Creating Certificates with elasticsearch-certutil

#CA and Node Certificates

The easiest way to manage certificates is with elasticsearch-certutil, the built-in tool:

bin/elasticsearch-certutil ca
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 --pem

The first command creates a CA (elastic-stack-ca.p12); the second creates per-node certificates signed by that CA. Certificates are installed into the node keystore (a .p12 file), and the CA is distributed to all nodes as the truststore.

#Certificate Renewal

Certificates have a validity period (5 years by default). Renewal must be planned, not done after expiration — a cluster with expired certificates fails inter-node communication and disconnects all clients. The pattern:

1. Create a new CA and certificates with elasticsearch-certutil.
2. Distribute the new certificates to all nodes.
3. Rolling restart nodes one by one (episode 30) while activating the new certificates.
4. Verify connectivity before the next node.

Schedule a reminder well before the validity period ends, and keep a renewal runbook — panicked renewal is a classic source of downtime.

#Bind and Publish Address

These two settings often confuse people but determine who can reach a node:

• network.host — the address the node binds to accept connections. 0.0.0.0 means all interfaces; 127.0.0.1 means only localhost.
• network.publish_host — the address published to other nodes so they can find it. Important in the cloud: bind to an internal IP, publish the IP other nodes can reach.

network.host: 0.0.0.0
network.publish_host: 10.0.1.5
discovery.seed_hosts: ["10.0.1.5:9300", "10.0.1.6:9300"]

If publish_host is wrong, other nodes can't find this node even though the bind is correct — a classic mistake when deploying to the cloud.

#Firewall and Network Isolation

Encryption stops eavesdropping; network isolation stops access. The ideal firewall rules for Elasticsearch:

Example with UFW on Ubuntu:

sudo ufw default deny incoming
sudo ufw allow from 10.0.1.0/24 to any port 9300
sudo ufw allow from 10.0.1.0/24 to any port 9200
sudo ufw allow from 10.0.2.10 to any port 5601

The main principle: deny by default. In the cloud, configure security groups with the same principle — port 9200 only opened to the application and admin subnets, port 9300 only between nodes, and everything inside a VPC not exposed to the internet.

#Common Mistakes

1. Self-signed certificates without a truststore. Clients fail verification — install the CA into the client truststore.

2. Certificates expiring without planning. The cluster suddenly loses communication — schedule renewals and renewal drills.

3. Transport TLS disabled. Opens the cluster's back door — always enable both.

4. Wrong publish_host in the cloud. Nodes can't be found — check the IP peers can actually reach.

5. Port 9200 open to the internet. An invitation to attack — deny by default and only open what's needed.

#Conclusion

In episode 16 you mastered network security and encryption: TLS for the HTTP and transport layers, creating CAs and certificates with elasticsearch-certutil, certificate renewal strategies with rolling restarts, bind vs publish host, and firewalls and network isolation at the port and VPC level.

Key takeaways:

• HTTP TLS protects the client path; transport TLS protects inter-node traffic — enable both.
• Certificates are created with elasticsearch-certutil and renewed before expiry.
• network.host for binding; network.publish_host for being found by other nodes.
• Deny-by-default firewalls: 9200 for clients, 9300 only between nodes.
• Defense in depth: encryption + authentication + network isolation together.

Now access is secure. But security also means being able to prove who accessed what. In episode 17 we'll cover audit logging and compliance: enabling audit logs, event types, file and index output formats, event filtering, and considerations for GDPR, data retention policies, and personal data handling. See you there!