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

一、安全体系总览:传输层与 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.username、elasticsearch.password 和 elasticsearch.ssl.certificateAuthorities 三项。
最后提醒一点:证书是有有效期的,自签 CA 默认五年。建议把证书到期时间纳入监控,提前用 openssl pkcs12 -in elastic-certificates.p12 -nokeys -clcerts | openssl x509 -noout -enddate 查看剩余有效期,避免某天集群因证书过期集体罢工。配置安全不是一次性工作,定期轮转密码、审计账号、检查证书,才能让集群长期稳定地安全运行。
Elasticsearch安全配置X-Pack集群认证修改时间:2026-09-06 15:56:46