给 Elasticsearch "穿上盔甲"——极限网关一招搞定 TLS 安全防护

铭毅天下Elasticsearch 2025-02-18

引言

读者经常有如下类似问题：

为什么要在 Elasticsearch 前面增加代理？
为什么要开启基本身份验证（Basic Auth）和 TLS？
如何配置一个简单易行的方案来实现上述需求？

一、为什么要在 Elasticsearch 前面增加代理？

1.1 直接暴露 Elasticsearch 的风险

很多团队在开发测试阶段，习惯了直接用 http://IP:9200
访问 ES（Elasticsearch），往往忽略了安全配置。

你的Elasticsearch在裸奔吗？

重要！！Elasticsearch 安全加固指南

如果没有任何鉴权或 TLS（加密传输），任何人只要能访问这个端口，就能读取、修改或删除数据，风险极高。

1.2 老版本或多版本集群的困扰

有些团队的 Elasticsearch 版本过旧，自身不支持开箱即用的 TLS 加密或用户鉴权。
还有部分团队同时运行多个不同版本的 ES，需要分别配置安全策略，手动管理非常麻烦。

1.3 通过网关代理可统一管理

借助“极限网关”这类代理服务，可以在网关层统一配置：

基本身份验证：让访问必须先“登录”
TLS：使用 HTTPS 加密传输，保护敏感数据

这样，就算内部是老版本的 Elasticsearch，也能在网关层快速补上“安全短板”，而无需立刻升级或修改 ES 自身的配置。

二、为什么要开启基本身份验证（Basic Auth）和 TLS？

2.1 Basic Auth——让访问必须先验证身份

问题：如果不做身份验证，谁都能访问你的 Elasticsearch，数据暴露极大。
解决方法：在网关上配置 Basic Auth，客户端只有提供正确的用户名和密码后才能访问后端 ES 集群。
好处：

快速阻断恶意或未知访问。
不需要在 Elasticsearch 本身额外安装插件（针对老版本尤其有用）。

2.2 TLS——让传输加密，防止密码和数据泄露

问题：仅有基本身份验证还不够，因为 HTTP 是明文传输，你的用户名和密码会在网络上裸奔。
解决方法：启用 TLS（HTTPS），这样就可以对通信进行加密。
好处：

有效防止中间人攻击或网络监听。
安全合规，减少数据泄露风险。

三、如何配置一个简单易行的方案来实现上述需求？

接下来，我们以“极限网关”（一个网关代理工具）为例，演示如何在前端快速搭建代理，并让后端的 Elasticsearch“无缝”升级到支持 Basic Auth + TLS。

思路概览：
先在网关配置好后端的 Elasticsearch 信息。

设置过滤器，把网关进来的请求转发到指定的 Elasticsearch。

开启 Basic Auth，设置用户名和密码。

再开启 TLS，把对外暴露的 HTTP 改为 HTTPS。

如果有历史原因，需要保留对 HTTP 的访问，可以再开一个“不安全端口”。

四、详细配置步骤

下面的示例配置文件大致分为三块：elasticsearch
、entry
、flow
（过滤器流）和 router
（路由）。其中关键点会在示例中标注出来。

详尽配置参数含义可以参考咱们之前发布文章：[1]极限网关 INFINI Gateway 配置文件核心解读 [2]极限网关 INFINI Gateway 从 0 到 1：简单易懂的入门教程

4.1 定义后端 Elasticsearch 资源

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

意义：定义一个名为 prod
的后端 Elasticsearch。

endpoint：实际的 ES 访问地址，这里假设是 192.168.3.201:9200
，不需要加 TLS，也不需要再改造 ES 本身。

4.2 建立入口（entry）并启用 TLS

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

意义：创建一个名为 my_es_entry
的网关入口，对外开放在 0.0.0.0:8000
并且开启 TLS。
binding：0.0.0.0
表示监听所有网卡 IP，为了安全可以改成内网地址或特定网卡 IP。
tls.enabled：开启后，你就可以通过 https://localhost:8000
来访问。
router：指定使用哪个路由规则（下面会介绍 my_router
）。

4.3 为历史系统保留 HTTP 访问（可选）

如果有遗留系统还无法切到 HTTPS，你可以再开一个“不安全”的入口：

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

意义：监听 0.0.0.0:8001
，不开启 TLS。
访问：http://localhost:8001
也能转发到后端 ES，但这是非加密，不建议长期使用。

4.4 设置过滤器流（flow）：添加 Basic Auth 和转发到 Elasticsearch

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

basic_auth：网关收到请求后，先检查用户名和密码，这里只配置了一个账号 medcl
密码 passwd
。
elasticsearch：如果鉴权通过，就把流量转发到上面定义的 prod
资源。

4.5 路由（router）把请求指向上面定义的 flow

router:
- name: my_router
default_flow: default_flow

意义：把名为 my_router
的路由默认指向 default_flow
。所有经这个路由的请求都会先经过上面定义的过滤器。

五、完整配置示例

以下是把所有部分合并在一起的例子：

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