Elasticsearch集群安全加固实战：配置密码认证与TLS加密

1. 项目概述：为什么Elasticsearch集群安全加固刻不容缓

如果你在生产环境用过Elasticsearch，大概率经历过这样的心跳时刻：某天突然发现，你的9200端口在公网上裸奔，任何人都能通过一个简单的HTTP请求，比如curl http://你的服务器IP:9200，把你集群里所有的索引、文档甚至配置信息一览无余。更可怕的是，如果这个集群还存着业务日志、用户行为数据，那基本等于把家门钥匙插在锁上。我见过太多团队，从开发到测试再到生产，一路都是默认配置跑到底，直到某次安全扫描亮起红灯，或者更糟——出了数据泄露事件，才手忙脚乱地开始补课。

“Elasticsearch 集群安全加固实战：从零配置访问密码与TLS加密”这个项目，就是针对这个普遍痛点的系统性解决方案。它不是一个简单的功能开关教程，而是一套从零开始，为你的Elasticsearch集群穿上“铠甲”的完整操作手册。核心目标就两个：第一，身份认证，确保只有知道账号密码的“自己人”才能访问集群；第二，传输加密，确保数据在网络中穿梭时是密文，防止被窃听或篡改。这不仅仅是满足等保合规的 checkbox，更是保护你核心数据资产的底线操作。

适合谁来参考？无论你是刚接手一个裸奔集群的运维工程师，还是正在搭建新数据平台的后端开发者，甚至是负责整体架构的安全负责人，这套实战流程都能给你一个清晰、可落地的路径。我们会基于最新的 Elastic Stack 8.x 版本（其安全功能已免费内置）来展开，同时也会兼顾一些仍在使用 7.x 版本的用户场景。整个过程会涉及 Elasticsearch 节点、Kibana 界面以及 Beats/Logstash 等数据采集器的联动配置，确保整个数据链路的安全闭环。

2. 安全加固的整体设计与核心思路拆解

在动手改配置之前，我们必须先理清 Elasticsearch 安全功能的架构和设计逻辑。很多人一上来就照着文档改elasticsearch.yml，结果发现 Kibana 连不上了，Logstash 报错了，整个链路乱成一团。根本原因在于没理解各个组件之间的信任关系是如何建立的。

2.1 免费的基础安全功能：X-Pack Security 不再是付费专属

一个重要的认知更新是：从 Elasticsearch 7.x 开始，基础安全功能（包括用户名/密码认证和 TLS 加密）已经免费包含在默认发行版中，无需购买白金版许可。早期版本中，这属于 X-Pack 的付费模块，但现在 Elastic 公司将其开源，极大地降低了安全门槛。我们所使用的elasticsearch-setup-passwords工具和 TLS 证书配置，都是这套基础安全功能的一部分。这打消了许多团队在成本上的顾虑，让安全加固成为必选项而非可选项。

2.2 双核心支柱：认证与加密的协同

本次加固围绕两大支柱展开，它们相互独立又互为补充：

1. 身份认证与授权：解决“你是谁”和“你能干什么”的问题。我们通过内置的native领域（即 Elasticsearch 自带的用户数据库）来创建用户和角色，并为角色分配精确的索引权限。例如，一个用于监控的readonly_user角色，可能只有对logstash-*这类索引的read权限，而无法删除索引或修改映射。

2. 传输层安全：解决“数据在路上是否安全”的问题。通过在集群节点之间、以及客户端与集群之间的通信链路上启用 TLS/SSL 加密，可以防止网络嗅探。这意味着即便有人截获了数据包，看到的也是一堆乱码。TLS 同时提供了双向认证的潜力，即服务器验证客户端，客户端也验证服务器，确保连接双方都是可信的。

2.3 核心配置逻辑：从“裸奔”到“全副武装”的过渡策略

最稳妥的加固策略不是在生产集群上直接开干，而是遵循“先测试，后生产；先内网，后公网”的原则。我的建议是：

1. 在测试环境搭建一个与生产环境版本一致的集群，完全模拟此次加固操作。
2. 先在一个隔离的内网环境中配置并验证所有功能，确保 Kibana、Beats 等客户端都能正常连接。
3. 制定详细的回滚方案，记录下修改前的每一个配置项。
4. 在生产环境实施时，选择业务低峰期，并分步骤进行：先配置 TLS 加密但暂不强制（允许明文回退），再启用密码认证但保留一个超级用户用于应急，最后全面强制安全策略。

这个思路的核心是“灰度”和“可观测”。每一步操作后，都要通过curl命令和 Kibana 界面验证服务是否正常，监控集群健康状态是否保持green。

3. 实战前准备：环境检查与必要工具

磨刀不误砍柴工，在开始修改配置前，我们必须确保环境处于一个可控和可回溯的状态。

3.1 环境与版本确认

首先，通过以下命令确认你的 Elasticsearch 版本和当前安全状态：

# 查看 Elasticsearch 版本和基础信息 curl -X GET "localhost:9200" # 检查安全功能是否已启用（7.x/8.x 返回内容不同） curl -X GET "localhost:9200/_xpack/usage?filter_path=security.enabled"

对于 8.x 集群，默认安全就是启用的，首次启动时会自动生成 TLS 证书和内置用户（如elastic）的密码。对于 7.x 集群，返回可能显示security.enabled: false。记下你的版本号，因为 7.8 到 7.16，以及 8.0 以上，部分配置参数和工具存在差异。

注意：如果你的集群是全新安装的 8.x，并且第一次启动时控制台打印出了elastic用户的随机密码，请务必妥善保存！那是你后续所有操作的钥匙。如果丢失了，后续操作会非常麻烦。

3.2 关键配置文件备份

这是最重要的步骤，没有之一。你需要备份以下文件：

• $ES_HOME/config/elasticsearch.yml: 主配置文件。
• $ES_HOME/config/elasticsearch.keystore: 存储敏感信息的密钥库文件（如果存在）。
• $ES_HOME/config/certs/(或类似目录): 任何现有的证书文件。

备份命令示例：

# 假设 ES_HOME 为 /usr/share/elasticsearch cp /usr/share/elasticsearch/config/elasticsearch.yml /usr/share/elasticsearch/config/elasticsearch.yml.bak.$(date +%Y%m%d)

同时，记录下当前集群所有节点的 IP 地址和主机名，这在配置 TLS 和发现种子主机时会用到。

3.3 证书工具准备：使用 Elasticsearch 自带的 elasticsearch-certutil

为了启用 TLS，我们需要为集群生成证书。最推荐的方式是使用 Elasticsearch 自带的elasticsearch-certutil工具。它简化了生成证书颁发机构（CA）和节点证书的过程。

# 进入 ES 安装目录的 bin 文件夹 cd /usr/share/elasticsearch/bin # 生成一个 CA（证书颁发机构） ./elasticsearch-certutil ca

执行命令后，它会交互式地询问一些信息（如 CA 名称、密码等），你也可以直接按回车使用默认值。完成后会得到一个elastic-stack-ca.p12文件。这个 CA 将用于为你所有的集群节点签署证书。

实操心得：给 CA 证书设置一个强密码并牢记。虽然后续操作可以生成无密码的证书方便自动化，但 CA 证书的密码是根密钥，必须离线安全保存。在生产环境中，可以考虑使用公司已有的内部 CA 来签发证书，这样更符合统一的安全管理体系。

4. 核心环节一：为集群通信套上“保险箱”——配置 TLS 加密

TLS 配置是第一步，也是相对复杂的一步。它的目标是让集群内节点之间（Transport Layer）和客户端到集群之间（HTTP Layer）的通信都经过加密。

4.1 生成节点证书与 TLS 配置

有了 CA 之后，我们需要为每个节点生成包含其主机名/IP的证书。

# 同样在 bin 目录下，生成节点证书 ./elasticsearch-certutil cert --ca elastic-stack-ca.p12 --name node1 --dns localhost,node1.yourdomain.com --ip 192.168.1.101,127.0.0.1

这里--dns和--ip参数至关重要，必须覆盖该节点可能被访问到的所有主机名和 IP 地址，包括localhost。否则在建立 TLS 连接时，会因主机名验证失败而报错。

假设你的集群有三个节点：node1 (192.168.1.101), node2 (192.168.1.102), node3 (192.168.1.103)。你需要为每个节点运行上述命令（或使用--multiple参数批量生成），得到类似node1.p12,node2.p12等文件。

接下来，将生成的.p12证书文件（以及 CA 文件，如果需要）复制到每个节点 Elasticsearch 配置目录下的子目录中，例如config/certs/。

mkdir -p /usr/share/elasticsearch/config/certs cp node1.p12 /usr/share/elasticsearch/config/certs/ cp elastic-stack-ca.p12 /usr/share/elasticsearch/config/certs/ # 可选，用于某些客户端验证

4.2 修改 elasticsearch.yml 启用 TLS

在每个节点的elasticsearch.yml中，添加或修改以下配置段：

# 节点名称和网络设置（根据实际情况修改） node.name: node1 network.host: 192.168.1.101 cluster.initial_master_nodes: ["node1", "node2", "node3"] discovery.seed_hosts: ["192.168.1.101:9300", "192.168.1.102:9300", "192.168.1.103:9300"] # ---------- 安全配置 ---------- xpack.security.enabled: true xpack.security.transport.ssl.enabled: true # 启用传输层 TLS xpack.security.transport.ssl.verification_mode: certificate # 验证证书 xpack.security.transport.ssl.keystore.path: certs/node1.p12 # 节点自己的证书 xpack.security.transport.ssl.truststore.path: certs/node1.p12 # 信任的证书库（这里用自己的，因为包含了CA链） xpack.security.http.ssl.enabled: true # 启用 HTTP 层 TLS (用于 REST API) xpack.security.http.ssl.keystore.path: certs/node1.p12 xpack.security.http.ssl.truststore.path: certs/node1.p12

关键参数解析：

• verification_mode: 设置为certificate表示验证证书的有效性和签名，而不强制验证主机名（full模式）。在内部集群通信中，使用certificate可以避免因内部IP或动态主机名导致的问题，是平衡安全与便利的常见选择。
• keystore.path和truststore.path: 这里我们简单起见，让每个节点用自己的p12文件同时作为密钥库和信任库。因为这个p12文件里包含了由我们自己的 CA 签发的节点证书以及 CA 的证书链，所以节点之间可以相互信任。

4.3 启动验证与常见问题

配置完成后，逐个重启Elasticsearch 节点（先重启主节点，再重启数据节点）。使用 HTTPS 和 9200 端口访问 API：

curl -k -X GET "https://localhost:9200"

由于我们使用的是自签名证书，-k参数忽略了证书验证。你应该会看到一个错误，提示需要认证（401 Unauthorized），这反而是好事！它说明两点：1. HTTPS 生效了；2. 安全认证被启用了。如果返回的是明文数据，说明 TLS 或安全功能未正确启用。

踩坑记录：最常见的问题是证书中的主体备用名称（SAN）没有包含节点用于通信的地址。例如，在discovery.seed_hosts里配置的是 IP，但证书里只写了 DNS 名，就会导致节点间无法建立 TLS 连接，集群无法形成。错误日志通常会包含 “SSLHandshakeException” 或 “hostname verification failed”。解决办法就是重新生成证书，确保--ip和--dns参数覆盖所有可能的地址。

5. 核心环节二：设置访问密码——告别“裸奔”API

TLS 保证了通道安全，接下来我们要在通道入口设置“门禁”。Elasticsearch 内置了一系列默认用户，如elastic（超级管理员）、kibana_system（Kibana 服务用户）、logstash_system等。我们需要为这些用户设置密码。

5.1 使用 setup-passwords 工具批量设置密码

最方便的工具是elasticsearch-setup-passwords。它位于 Elasticsearch 的bin目录下。确保所有节点都已启动且 TLS 配置生效后，在一个节点上执行：

# 交互式设置所有内置用户密码 ./elasticsearch-setup-passwords interactive # 或者，自动生成随机密码（适用于脚本化部署） ./elasticsearch-setup-passwords auto

interactive模式会依次提示你为elastic、apm_system、kibana_system、logstash_system、beats_system、remote_monitoring_user等用户设置密码。请务必为elastic用户设置一个极其复杂且妥善保管的密码，这是你的“根密钥”。

auto模式会为所有用户生成随机密码并打印在终端上，你必须立即保存这些密码。这个输出只会显示一次。

5.2 验证密码认证

密码设置完成后，再次访问 API 就必须提供凭证了：

# 使用 -u 参数提供用户名密码 curl -k -u elastic:你设置的密码 -X GET "https://localhost:9200/_cluster/health?pretty"

如果命令返回了集群的健康状态（green/yellow/red），恭喜你，密码认证已成功启用。现在，你的 Elasticsearch REST API 再也不是谁都能调用的了。

5.3 创建自定义用户与角色（按需）

内置用户主要用于系统服务。对于业务应用或团队成员，你应该创建权限最小化的自定义用户。

# 1. 创建角色，定义权限 curl -k -u elastic:密码 -X POST "https://localhost:9200/_security/role/app_readonly_role" -H 'Content-Type: application/json' -d' { "indices": [ { "names": ["myapp-*"], "privileges": ["read", "view_index_metadata"] } ] } ' # 2. 创建用户，并关联角色 curl -k -u elastic:密码 -X POST "https://localhost:9200/_security/user/app_reader" -H 'Content-Type: application/json' -d' { "password": "StrongPassword123!", "roles": ["app_readonly_role"], "full_name": "Application Readonly User" } '

这样，你就创建了一个只能读取myapp-开头的索引的用户app_reader。遵循最小权限原则是安全架构的基石。

6. 核心环节三：配置 Kibana 以连接安全集群

Kibana 作为最重要的客户端，也需要配置才能连接上开启了安全和 TLS 的 Elasticsearch。

6.1 修改 kibana.yml 配置

找到 Kibana 的配置文件kibana.yml，通常位于/etc/kibana/或 Kibana 安装目录的config文件夹下。关键配置如下：

# Kibana 服务端口 server.port: 5601 server.host: "0.0.0.0" # 按需修改 # 连接安全的 Elasticsearch elasticsearch.hosts: ["https://你的ES节点IP:9200"] elasticsearch.username: "kibana_system" # 使用专门的 kibana_system 用户 elasticsearch.password: "你为kibana_system设置的密码" # 由于 ES 使用了自签名证书，Kibana 需要验证，这里提供 CA 证书路径 elasticsearch.ssl.certificateAuthorities: [ "/path/to/your/elastic-stack-ca.p12" ] # 或者，如果不方便提供CA证书，可以暂时关闭验证（仅限测试） # elasticsearch.ssl.verificationMode: none

重要提醒：不要使用elastic超级用户来运行 Kibana！应该使用权限更受限制的kibana_system内置用户。这个用户拥有 Kibana 运行所需的最低必要权限。

6.2 启动 Kibana 并登录

启动 Kibana 服务后，访问其 Web 界面 (http://你的服务器IP:5601)。首次访问时，它会跳转到登录页面。在这里，你可以使用elastic超级用户或其他你创建的用户登录。

注意事项：如果 Kibana 启动失败，查看日志 (journalctl -u kibana或logs/kibana.log) 是首要操作。最常见的错误是：

1. 证书验证失败：确保elasticsearch.ssl.certificateAuthorities路径正确，且 Kibana 进程有权限读取该文件。或者确认证书的 SAN 包含了 Elasticsearch 节点的地址。
2. 认证失败：检查kibana_system用户的密码是否正确，以及该用户是否在 Elasticsearch 中处于启用状态。
3. 网络连接失败：检查elasticsearch.hosts的地址和端口是否能从 Kibana 服务器正常访问，防火墙是否放行了 9200 端口。

7. 核心环节四：配置 Beats/Logstash 等数据采集器

数据采集端（如 Filebeat, Metricbeat, Logstash）同样需要配置凭证和证书才能向安全的集群写入数据。

7.1 以 Filebeat 为例的配置

编辑 Filebeat 的配置文件filebeat.yml：

output.elasticsearch: hosts: ["https://你的ES节点IP:9200"] username: "beats_system" # 或你创建的具有写入权限的专用用户 password: "对应用户的密码" ssl.enabled: true ssl.certificate_authorities: ["/path/to/elastic-stack-ca.p12"] # ssl.verification_mode: "none" # 测试时可暂时关闭验证

这里推荐使用内置的beats_system用户，或者为其创建一个专属角色，只授予对特定索引模板和索引的写入权限。

7.2 Logstash 的配置

在 Logstash 的 pipeline 配置文件中，配置 Elasticsearch output 插件：

output { elasticsearch { hosts => ["https://你的ES节点IP:9200"] user => "logstash_writer" # 建议创建专用用户 password => "专用用户密码" ssl => true cacert => "/path/to/elastic-stack-ca.p12" index => "myapp-logs-%{+YYYY.MM.dd}" } }

7.3 客户端配置的通用原则

1. 专用用户：为每一类客户端（Kibana, Beats, Logstash, 业务应用）创建独立的用户和角色，实现权限隔离。
2. 最小权限：角色的权限只赋予其完成工作所必需的最少操作。例如，一个只负责写入日志的 Beat 用户，不应该有读取或删除索引的权限。
3. 证书管理：将 CA 证书安全地分发给所有需要连接 ES 的客户端机器。可以考虑使用配置管理工具（如 Ansible, Puppet）或密钥管理服务来分发，避免硬编码在配置文件中。

8. 高级加固与生产环境考量

基础的安全堡垒搭建完成后，我们可以进一步构筑纵深防御。

8.1 启用审计日志记录谁干了什么

审计日志能记录所有对集群的访问和操作尝试，对于安全事件追溯和合规审计至关重要。在elasticsearch.yml中启用：

xpack.security.audit.enabled: true xpack.security.audit.logfile.events.include: access_denied, access_granted, anonymous_access_denied, authentication_failed, connection_denied, tampered_request, run_as_denied, run_as_granted xpack.security.audit.logfile.events.exclude: _all

配置后，审计日志会输出到logs/目录下的独立文件。你需要定期归档和分析这些日志，可以配合 Filebeat 将其摄入另一个专门的监控集群。

8.2 配置基于角色的访问控制精细化权限

前面我们创建了简单的角色。在生产中，权限需要更精细。例如，为一个开发团队创建角色：

{ "cluster": ["monitor"], // 允许查看集群状态 "indices": [ { "names": ["project-dev-*"], "privileges": ["all"] // 对开发索引有全部权限 }, { "names": ["project-prod-*"], "privileges": ["read"] // 对生产索引只有读权限 }, { "names": [".kibana_*"], "privileges": ["manage"] // 允许管理自己的 Kibana 空间 } ] }

通过精细的 RBAC，可以实现多租户环境下的数据隔离。

8.3 网络层加固：防火墙与反向代理

不要将 Elasticsearch 的 9200（HTTP）和 9300（Transport）端口直接暴露在公网。应严格使用防火墙规则，只允许 Kibana 服务器、Logstash 服务器和特定的应用服务器 IP 访问 9200 端口。节点间的 9300 端口通信应限制在集群内部网络。

更进一步，可以在 Elasticsearch 前面部署一个反向代理（如 Nginx）。由 Nginx 终止 TLS，并承担负载均衡、限流、基础认证等任务，Elasticsearch 本身只监听本地回环地址127.0.0.1。这样可以将攻击面降到最低。

9. 故障排查与日常维护清单

安全加固后，日常运维和问题排查会有些许不同。这里整理了一份速查表。

日常维护建议：

• 密码轮换：定期（如每90天）更新elastic、kibana_system等关键用户的密码，并同步更新所有相关客户端的配置。
• 证书管理：监控证书有效期，建议设置自动续期流程，避免证书过期导致服务中断。自签名证书通常有效期为1年。
• 审计日志监控：定期检查审计日志，关注大量的authentication_failed或access_denied事件，这可能是暴力破解或异常访问的迹象。
• 版本升级：在升级 Elastic Stack 版本前，务必在测试环境验证安全配置的兼容性。大版本升级（如 7.x 到 8.x）时，安全配置可能有重大变化。

安全加固不是一次性的任务，而是一个持续的过程。从配置密码和 TLS 开始，建立起基本防线，再通过审计、网络隔离、精细权限控制不断深化，你的 Elasticsearch 集群才能真正称得上“固若金汤”。这套组合拳打下来，无论是应对内部误操作还是外部恶意攻击，你都会有充足的信心和有效的手段。