Secure Elasticsearch with a Single InfinI Gateway: Adding TLS and Basic Auth

Introduction

Many teams expose Elasticsearch directly during development (e.g., http://IP:9200) and overlook security, leaving the service vulnerable to unauthorized read, write, or delete operations.

Why add a proxy in front of Elasticsearch?

1.1 Direct exposure risks

Without authentication or TLS, anyone who can reach the port can manipulate data.

1.2 Issues with old or mixed‑version clusters

Older ES versions lack built‑in TLS or user authentication.

Running multiple ES versions requires separate security policies, which is cumbersome to manage manually.

1.3 Unified management via a gateway

Using a gateway such as InfinI Gateway allows centralized configuration of:

Basic Authentication – forces a login before access.

TLS – encrypts traffic with HTTPS.

This lets even legacy ES instances gain security without upgrading or changing their own configuration.

Why enable Basic Auth and TLS?

2.1 Basic Auth – enforce identity verification

Problem: Without authentication, the ES cluster is openly accessible.

Solution: Configure Basic Auth on the gateway; only clients providing the correct username and password can reach the backend.

Benefits:

Quickly block malicious or unknown access.

No need to install additional plugins on ES, which is especially useful for older versions.

2.2 TLS – encrypt transmission to prevent credential and data leakage

Problem: HTTP transmits credentials in clear text.

Solution: Enable TLS (HTTPS) to encrypt the communication.

Benefits:

Effective protection against man‑in‑the‑middle attacks and network sniffing.

Improved compliance and reduced risk of data leakage.

How to configure a simple solution

Using InfinI Gateway, the following steps create a proxy that adds Basic Auth and TLS while keeping the original ES configuration untouched.

Overview: Define the backend Elasticsearch resource. Configure an entry (frontend) that listens on a chosen port. Enable Basic Auth with a username/password. Enable TLS to expose HTTPS. (Optional) Add an insecure HTTP entry for legacy systems.

4.1 Define backend Elasticsearch resource

elasticsearch:
- name: prod
  enabled: true
  endpoint: http://192.168.3.201:9200

Meaning: Defines a backend named prod with the actual ES address. No TLS is required here.

4.2 Create an entry and enable TLS

entry:
- name: my_es_entry
  enabled: true
  router: my_router
  max_concurrency: 10000
  network:
    binding: 0.0.0.0:8000
  tls:
    enabled: true

Meaning: Exposes the gateway at 0.0.0.0:8000 with TLS enabled, routing traffic through my_router.

4.3 Optional insecure HTTP entry

- name: my_unsecure_es_entry
  enabled: true
  router: my_router
  max_concurrency: 10000
  network:
    binding: 0.0.0.0:8001
  tls:
    enabled: false

Provides a legacy HTTP endpoint ( 0.0.0.0:8001) without TLS; not recommended for long‑term use.

4.4 Define the flow: Basic Auth then forward to Elasticsearch

flow:
- name: default_flow
  filter:
  - basic_auth:
      valid_users:
        medcl: passwd
  - elasticsearch:
      elasticsearch: prod

basic_auth: Checks the supplied username/password (example user medcl with password passwd).

elasticsearch: After successful authentication, forwards the request to the backend prod.

4.5 Router linking entry to flow

router:
- name: my_router
  default_flow: default_flow

Routes all incoming requests through default_flow, ensuring they pass the defined filters.

Full configuration example

elasticsearch:
- name: prod
  enabled: true
  endpoint: https://127.0.0.1:9200
  basic_auth:
    username: elastic
    password: changeme

entry:
- name: my_es_entry
  enabled: true
  router: my_router
  max_concurrency: 10000
  network:
    binding: 0.0.0.0:8000
  tls:
    enabled: true

- name: my_unsecure_es_entry
  enabled: true
  router: my_router
  max_concurrency: 10000
  network:
    binding: 0.0.0.0:8001
  tls:
    enabled: false

flow:
- name: default_flow
  filter:
  - basic_auth:
      valid_users:
        elastic: changeme
  - elasticsearch:
      elasticsearch: prod

router:
- name: my_router
  default_flow: default_flow

Verification

HTTPS request: Access https://localhost:8000; the browser prompts for credentials. After successful login, operations are performed on the prod ES cluster.

Linux curl test: Demonstrates successful authentication and data read/write.

Python program: Shows read and write operations succeed through the gateway.

HTTP fallback (optional): Access http://localhost:8001 with the same credentials; traffic is unencrypted and therefore not recommended for production.

Conclusion

The gateway solves security gaps for old or multi‑version Elasticsearch clusters without changing the clusters themselves.

Unified management is achieved by configuring Basic Auth and TLS once at the gateway level.

Applicable scenarios include legacy ES versions lacking native security, quick security hardening for test or production environments, and environments running several ES versions.

Future extensions can add IP whitelists, rate limiting, or combine load balancers for higher throughput.