让 Kibana 更安全、更灵活——用极限网关一键搞定

铭毅天下Elasticsearch 2025-02-19

162

一、为什么要给 Kibana 加代理和安全？

1.1 问题：Kibana 可能被直接暴露

Kibana 用来可视化和管理 Elasticsearch 数据，一旦后台没设置访问控制，任何人都能访问到你的数据。
很多团队使用旧版本或默认配置的 Kibana，没有开 TLS、没有设置登录验证，可能就暴露在公网或内网。
如果大家关注过下面的文章，应该有过初步了解。下文中的 IP 地址是借助 Hping 类似的扫描工具公开获取的开放 9200、5601 端口的公网服务器。
基于 Elasticsearch + kibana 实现 IP 地址分布地图可视化

1.2 风险：谁都能动你的分析和可视化

未经授权的用户可以直接查看甚至修改索引、仪表盘等资源，带来数据泄露或误删风险。
开发/测试环境常常懒得配置安全，但一旦上线，又容易“带着漏洞”进入生产环境。

1.3 解决思路：用网关统一加上“保护壳”

借助“极限网关”这种代理工具，可以在网关层快速给 Kibana 加上：

身份验证（Basic Auth）
TLS 加密（HTTPS）
更强的自定义替换和路由规则

无需修改 Kibana 本身的配置，对于旧版本也能管用。

二、能解决什么问题？有哪些应用场景？

2.1 快速安全加固

无论你是旧版 Kibana，还是多版本共存，都能用网关一次性加上用户名/密码和 HTTPS。
这样即使 Kibana 不自带安全功能，也能防止随意访问。

2.2 灵活定制前端内容

除了安全控制，还可以利用网关来“拦截”某些静态资源或路由请求，进行替换或跳转，比如更换 Logo、插入自定义 JS/CSS 等。

2.3 场景示例

内网环境：不想每个开发都能访问 Kibana，但又不想配置一堆插件，就用网关加一道门。
外网环境：把 Kibana 暴露到公网上时，必须要有加密和身份验证，否则风险太大。
多版本升级过渡：某些老版本 Kibana 不支持官方安全插件，网关层可以快速提供“补丁式”安全。

三、如何配置？（示例方案）

以下示例展示了如何在极限网关上添加代理、身份验证、TLS，以及实现对 Kibana 静态资源的替换。

3.1 在网关前面开启 TLS 代理

在配置文件中，entry
部分表示网关对外暴露的入口地址：

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

binding: 0.0.0.0:8000：网关监听 0.0.0.0 的 8000 端口，表示所有网卡都可访问。为安全可以改成本地 IP。
tls.enabled: true：开启 HTTPS，让传输加密，避免用户名密码明文暴露。

现在，客户端需要通过 https://<网关IP>:8000
才能访问 Kibana。

3.2 给 Kibana 加 Basic Auth 验证

在 flow
里定义过滤器，对每个请求先做 Basic Auth 验证：

flow:
  - name: default_flow
    filter:
      - basic_auth:
          valid_users:
            medcl: passwd
      - http:
          schema: "http" # 也可以写 https，根据你的 Kibana 是否启用了 TLS
          host: "192.168.3.188:5602"

basic_auth：只有用户名 medcl
、密码 passwd
输入正确，才能继续访问后端的 Kibana。
http：将通过网关的请求转发到真实的 Kibana 实例，比如 192.168.3.188:5602
。

3.3 替换静态资源：自定义 Logo 或插图

如果想让 Kibana 的某些静态资源指向自己的图片，可以用“替换资源”的流（flow）和路由（router）规则：

  - name: replace_logo_flow
    filter:
      - redirect:
          uri: https://elasticsearch.cn/uploads/event/20211120/458c74ca3169260dbb2308dd06ef930a.png

表示当命中这个 flow 时，把请求重定向到指定的图片链接。这样，Kibana 原本的某张插图就会显示你的自定义图片。

3.4 配合路由规则，灵活控制请求流向

在 router
中可以定义规则，哪些请求路径或方法应该走哪个 flow：

router:
  - name: my_router
    default_flow: default_flow
    rules:
      - method:
          - GET
          - POST
        pattern:
          - "/_logout"
        flow:
          - logout_flow
      - method:
          - GET
        pattern:
          - "/plugins/kibanaReact/assets/illustration_cloud_migration.png"
        flow:
          - replace_logo_flow

默认规则：走 default_flow
，进行 Basic Auth，然后转发到 Kibana。
自定义规则：

/_logout
用于登出时，先执行 logout_flow
，返回特定的退出提示。
请求 /plugins/kibanaReact/assets/illustration_cloud_migration.png
时走 replace_logo_flow
，替换为自定义图片。

3.5 一个完整示例配置

把上面提到的所有部分合并，就构成一个可用的网关配置：

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




flow:
  - name: logout_flow
    filter:
      - set_response:
          status: 401
          body: "Success logout!"
      - drop:
  - name: replace_logo_flow
    filter:
      - redirect:
          uri: https://elasticsearch.cn/uploads/event/20211120/458c74ca3169260dbb2308dd06ef930a.png
  - name: default_flow
    filter:
      - basic_auth:
          valid_users:
            elastic: changeme
      - http:
          schema: "http" #https or http
          host: "10.0.8.2:5601"
router:
  - name: my_router
    default_flow: default_flow
    rules:
      - method:
          - GET
          - POST
        pattern:
          - "/_logout"
        flow:
          - logout_flow
      - method:
          - GET
        pattern:
          - "/plugins/kibanaReact/assets/illustration_cloud_migration.png"
        flow:
          - replace_logo_flow