Secure Your Elasticsearch with INFINI Gateway: TLS, Auth, Multi‑Tenant & HA Guide

Why Add a Security Proxy to Elasticsearch?

Many deployments expose Elasticsearch (ES) directly to the internet without enabling built‑in security, leaving ports 9200/9300 unauthenticated and unencrypted. This permits destructive commands such as DELETE /* and makes the cluster a frequent target for data leaks and attacks. Older versions (5.x/6.x) often lack X‑Pack Security and cannot be upgraded easily, so an external, non‑intrusive security layer is required.

INFINI Gateway Overview

TLS‑encrypted HTTPS traffic

Basic authentication

Single unified entry point

Multi‑tenant routing and rate‑limiting

Auditing and fine‑grained access control

Architecture

Key flow:

Client → TLS + Basic Auth → Gateway

Gateway → internal HTTP → Elasticsearch

Elasticsearch remains non‑public

Gateway can be deployed in HA mode

Production‑Ready Configuration (gateway-config.yml)

elasticsearch:
  - name: prod
    enabled: true
    endpoint: http://192.168.3.201:9200
    # Backend ES may have no authentication
    # basic_auth:
    #   username: esuser
    #   password: espass

entry:
  - name: secure_entry
    enabled: true
    router: es_router
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true
      certificate_path: /etc/gw/cert.pem
      private_key_path: /etc/gw/key.pem

flow:
  - name: default_flow
    filter:
      - basic_auth:
          valid_users:
            admin: StrongPassword_234
            data_team: DevTeam_Secret
      - elasticsearch:
          elasticsearch: prod

router:
  - name: es_router
    default_flow: default_flow

1. TLS Encryption

The gateway terminates TLS, allowing the backend ES to use plain HTTP while external traffic is encrypted.

2. Basic Authentication

curl -u admin:StrongPassword_234 https://your-gw:8000

3. Flow – Filter Chain

A flow defines the ordered list of filters applied to each request, e.g., Basic Auth, rate‑limiting, auditing, request transformation, and routing.

4. Router – Multi‑Tenant Routing

/tenantA/* → A index
/tenantB/* → B index

Typical Enterprise Scenarios

Legacy ES versions without built‑in security – the gateway adds protection without code changes.

Secure Kibana access for multiple departments – enforce Basic Auth, restrict write operations, and apply rate‑limiting.

Multi‑tenant isolation – separate traffic for different teams, enforce distinct rate limits, and route to different clusters.

Expose query APIs to partners – enforce authentication, audit access, and limit visible indices.

Cross‑region encrypted access – TLS + Basic Auth protect traffic over unstable links.

Unified access layer for micro‑services – supports canary releases, blue‑green deployments, auditing, and rate‑limiting.

Risk Cases Demonstrating Need for a Gateway

Plain‑text traffic capture – attackers can see queries, user data, results, and index structures. TLS encryption blocks this.

Unauthenticated DELETE /* – a malicious actor can wipe an entire cluster. Basic Auth with permission rules prevents it.

Kibana exposed without auth – vulnerable to script injection. The gateway can restrict IPs, enforce Basic Auth, limit write operations, and add TLS.

Best Practices for Production Deployment

High Availability – deploy two gateways behind a virtual IP (VIP) using Keepalived/LVS/Nginx and run at least three ES nodes. Client → VIP → GW1/GW2 → ES Never store passwords in plain YAML – use environment variables, Kubernetes Secrets, HashiCorp Vault, or cloud KMS services.

Enable detailed logging and audit – capture user access counts, failed logins, error responses, latency, and source IPs. Forward logs to Filebeat → Elasticsearch and visualize via Kibana dashboards.

Rate‑limit to protect ES – example configuration:

- rate_limit:
    rpm: 2000

Gradual migration (canary/blue‑green) – route a fraction of traffic to a new ES cluster for version upgrades, storage migrations, or blue‑green deployments.

FAQ

Can the backend ES run without TLS? Yes. The gateway terminates TLS for external traffic.

What if ES itself has a password? Front‑end authentication is independent; the gateway can add backend Basic Auth when forwarding requests.

Can Kibana be accessed through the gateway? Yes, and it is strongly recommended.

Performance impact? Typically 0.1–0.5 ms per request, which is negligible.

Conclusion

Deploying INFINI Gateway enables TLS encryption, basic authentication, a unified entry point, rate‑limiting, auditing, multi‑tenant routing, access control, and high‑availability for any Elasticsearch version—especially legacy installations—without modifying existing applications, client libraries, or ES configurations.