导读:本期聚焦于王柏年创作的《如何正确配置 Elasticsearch 安全认证与 X-Pack 防护机制?》,敬请观看详情。默认安装的 Elasticsearch 集群就像一扇没上锁的门,任何人拿到地址就能直接读写甚至删除索引数据,这类安全事故在生产环境并不少见。X-Pack 作为 Elasticsearch 官方的安全组件,提供了传输层加密、身份认证、基于角色的访问控制以及审计日志等一整套能力,从 6.8 和 7.0 版本开始免费开放基础安全功能。本文围绕安全证书的生成流程展开,详细讲解如何为节点间通信启用 TLS 加密、如何为 HTTP 层配置身份验证、如何创建角色和用户实现细粒度权限控制,并整理了内置于 elastic、kibana_system 等内置账号的用途与密码修改注意事项,最后给出常见报错的排查思路,帮助你把集群从裸奔状态升级到安全可用的生产标准。

Elasticsearch 在默认配置下不启用任何安全机制,任何能访问 9200 端口的人都可以查看、修改甚至删除整个集群的数据。很多团队在内网环境中图省事长期裸奔运行,一旦集群地址泄露或者服务器被横向渗透,后果往往不可挽回。X-Pack 是 Elastic 官方提供的安全套件,从 6.8 和 7.0 版本开始,原本收费的基础安全功能(TLS 加密、认证、基于角色的访问控制)已经免费开放,生产集群没有任何理由不开起来。本文将从证书生成、传输层加密、HTTP 认证、用户权限管理几个方面,完整梳理一套可落地的安全配置方案。

如何正确配置 Elasticsearch 安全认证与 X-Pack 防护机制?

一、安全体系总览:传输层与 HTTP 层是两回事

很多初学者会把 Elasticsearch 的两层通信混为一谈,导致证书配置错误。实际上集群里存在两条完全独立的通信通道:第一条是传输层(transport 层),运行在 9300 端口,用于节点之间组成集群、同步集群状态、复制分片数据;第二条是 HTTP 层,运行在 9200 端口,用于接收客户端的 REST 请求。

这两层的安全需求不同。传输层必须在组建集群时就配置 TLS 证书,否则任何一个能连通 9300 端口的进程都可能伪装成节点加入集群,直接获取全部数据,这是 Elasticsearch 历史上多次重大漏洞的攻击路径。HTTP 层则负责面向应用和用户,需要开启身份认证,并对外提供 HTTPS 加密,防止凭据在公网或不可信网络中明文传输。

配置顺序上建议先做传输层再做 HTTP 层。因为传输层证书是集群能否正常启动的前提,而 HTTP 认证可以在集群跑起来之后再逐步启用,给客户端留出改造时间。整个流程可以用官方提供的 elasticsearch-certutil 工具完成,下面逐一展开。

二、生成证书并配置传输层 TLS 加密

第一步是生成证书颁发机构(CA)和节点证书。进入 Elasticsearch 安装目录,执行下面的命令生成 CA,输出文件为 elastic-stack-ca.p12:

cd /usr/share/elasticsearch
bin/elasticsearch-certutil ca --out elastic-stack-ca.p12 --pass ""
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 --ca-pass "" --out elastic-certificates.p12 --pass ""

这里建议在测试环境使用空密码,避免配置文件里明文写密码的同时又引入 keystore 管理成本。生产环境更规范的做法是把密码存入 keystore:

bin/elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password
bin/elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password

拿到 elastic-certificates.p12 后,把它复制到每个节点的 config 目录(或统一的证书目录),然后在 elasticsearch.yml 中添加传输层配置:

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/certs/elastic-certificates.p12

这里有一个容易踩的坑:verification_mode 有 full、certificate、none 三档。certificate 模式只验证证书是否由信任的 CA 签发,不校验主机名,适合多节点使用同一份证书的场景;如果为每个节点签发了独立证书并带有 SAN 主机名,可以用 full 模式获得更强的校验。配置完成后逐个滚动重启节点,用 GET _cluster/health 确认集群状态为 green,再进行下一步。

三、开启 HTTP 层认证与 HTTPS

传输层加密完成后,就可以给 HTTP 层开锁了。首先为 HTTP 层生成证书,可以直接用 elasticsearch-certutil http 命令交互式生成,也可以复用之前的 CA:

bin/elasticsearch-certutil http
# 按提示选择是否已有 CA,输入 elastic-stack-ca.p12
# 输出 http.p12,其中同时包含证书与私钥
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: /etc/elasticsearch/certs/http.p12
xpack.security.http.ssl.keystore.secure_password: ""

重启后集群会自动生成几个内置账号,需要用 elasticsearch-setup-passwords 设置密码(7.x 版本)。在 8.x 版本中,安装包默认已开启安全,首次启动时会在日志中输出 elastic 用户的初始密码,改密则使用 elasticsearch-reset-password 工具:

bin/elasticsearch-setup-passwords interactive
# 或 8.x:
bin/elasticsearch-reset-password -u elastic

内置账号各有分工,务必区别对待:elastic 是超级管理员,只应留给运维应急使用;kibana_system 供 Kibana 连接集群使用;logstash_system 供 Logstash 监控上报使用。验证方式很简单,带上凭据访问即可:

curl -k -u elastic:你的密码 https://127.0.0.1:9200/_cluster/health?pretty

四、角色与用户:最小权限原则落地

认证解决的是「你是谁」,授权解决的是「你能做什么」。X-Pack 的 RBAC 模型中,角色定义了一组权限,用户被绑定到一个或多个角色。典型的错误做法是给所有业务方都发 elastic 账号,这等于白做了前面的所有安全配置。

举个例子,假设有一个日志查询系统,只需要读取 logs-* 索引,可以创建一个专用角色:

POST _security/role/log_reader
{
  "indices": [
    {
      "names": ["logs-*"],
      "privileges": ["read", "view_index_metadata"]
    }
  ]
}

POST _security/user/log_app
{
  "password": "强密码",
  "roles": ["log_reader"]
}

权限粒度可以做到很细:索引级别有 read、write、delete、create_index 等;集群级别有 manage、monitor 等;还可以通过字段级安全(field level security)和文档级安全(document level security)限制角色只能看到特定字段或满足某个查询条件的文档,这对多租户场景非常实用。例如给角色加 "field_security": {"grant": ["message", "@timestamp"]},用户就看不到其他字段了。

对于 Kibana 侧的使用,建议为普通开发人员分配 kibana_dashboard_only_user 之类的只读角色,把空间隔离交给 Kibana Spaces 处理,避免有人误操作删除索引。如果内置角色不够用,再按上面方式自定义,但始终遵循最小权限原则:默认不给,用到再给,定期用 GET _security/user 审计一遍账号清单。

五、常见报错与排查思路

安全配置上线后最常见的报错是 unable to find valid certification path to requested target,这出现在 Java 客户端连接 HTTPS 集群时,原因是客户端不信任自签 CA。解决办法是把 CA 证书导入客户端信任库,或在 REST 客户端构建时禁用主机名校验但保留证书校验,切勿图省事直接关闭全部校验。

第二个高频问题是节点反复脱离集群,日志中出现 received plaintext http traffic on an https channel,说明某个节点的 HTTP 层没有开启 SSL,而负载均衡或其他节点按 HTTPS 访问了它。逐台核对 elasticsearch.yml 中安全相关配置是否一致即可。第三个是 Kibana 连不上集群,多数是 kibana_system 密码不对或没有配置 CA 信任,检查 kibana.yml 中的 elasticsearch.usernameelasticsearch.passwordelasticsearch.ssl.certificateAuthorities 三项。

最后提醒一点:证书是有有效期的,自签 CA 默认五年。建议把证书到期时间纳入监控,提前用 openssl pkcs12 -in elastic-certificates.p12 -nokeys -clcerts | openssl x509 -noout -enddate 查看剩余有效期,避免某天集群因证书过期集体罢工。配置安全不是一次性工作,定期轮转密码、审计账号、检查证书,才能让集群长期稳定地安全运行。

Elasticsearch安全配置X-Pack集群认证修改时间:2026-09-06 15:56:46

免责声明:已尽一切努力确保本网站所含信息的准确性。网站作品多为原创整理与精心创作,观点力求客观中立。本站旨在免费分享,内容仅供个人学习、研究或参考使用。若引用了第三方作品,版权归原作者所有。如内容涉及您的权益,请联系我们进行处理Email:chomcom@qq.com。
引用或转载本作品时,请注明当前出处:https://www.ipipp.com/html/20260906/51643.html,基于非商业用途的前提下,欢迎转载或二创本作品。
内容垂直聚焦
专注技术核心技术栏目,确保每篇文章深度聚焦于实用技能。从代码技巧到架构设计,为用户提供无干扰的纯技术知识沉淀,精准满足专业提升需求。
知识结构清晰
覆盖从开发到部署的全链路。AI、前端、编程、数据库、服务器、建站、系统层层递进,构建清晰学习路径,帮助用户系统化掌握开发与运维所需的核心技术。
深度技术解析
拒绝泛泛而谈,深入技术细节与实践难点。无论是数据库优化还是服务器配置,均结合真实场景与代码示例进行剖析,致力于提供可直接应用于工作的解决方案。
专业领域覆盖
精准对应开发生命周期。从前端界面到后端编程,从数据库操作到服务器运维,形成完整闭环,一站式满足全栈工程师和运维人员的技术需求。
即学即用高效
内容强调实操性,步骤清晰、代码完整。用户可根据教程直接复现和应用于自身项目,显著缩短从学习到实践的距离,快速解决开发中的具体问题。
持续更新保障
专注既定技术方向进行长期、稳定的内容输出。确保各栏目技术文章持续更新迭代,紧跟主流技术发展趋势,为用户提供经久不衰的学习价值。