从“裸奔”到零信任：一位老运维亲历的 Elasticsearch 密码安全实战手记
去年冬天，我接手一个刚被通报存在高危漏洞的银行日志平台——三台 Elasticsearch 节点直接暴露在公网，curl http://x.x.x.x:9200/_cat/indices?v一行命令就能拉出全部索引名，kibana_system用户密码还是默认值。更惊心的是，审计日志里有 73 次来自境外 IP 的/_search?size=10000请求，目标直指credit-card-*和idv-verify-*这类索引。
这不是演习，是真实发生过的“数据裸奔”。而今天我要讲的，不是教科书式的概念堆砌，而是过去两年在金融、政务、IoT 多个生产环境里，踩过坑、调过参、扛过压后沉淀下来的Elasticsearch 密码安全落地真经——不谈虚的合规条文，只说怎么让elasticsearch设置密码真正管用、可控、可持续。
一、别急着设密码，先让 Security 模块“活下来”
很多团队第一步就卡住了：改完xpack.security.enabled: true，重启失败，日志里满屏SSLHandshakeException或CertificateException。不是配置写错了，而是没理解Security 模块的启动逻辑本质是“全链路 TLS 强制校验”。
从 7.10 开始，Elasticsearch 已把“加密通信”从可选项变成了生存前提。它不像 Nginx 那样允许 HTTP 和 HTTPS 并存；一旦启用 Security，所有节点间通信（transport）、所有客户端访问（http），必须走 TLS，且证书必须能互相验证。
关键配置不是“越多越好”，而是“精准闭环”
# elasticsearch.yml —— 这不是模板，是运行时契约 xpack.security.enabled: true # transport 层（节点间）：必须双向认证，证书互信 xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.keystore.path: certs/elastic-node.p12 xpack.security.transport.ssl.truststore.path: certs/elastic-node.p12 # http 层（客户端）：同样强制 TLS，但可灵活选择验证强度 xpack.security.http.ssl.enabled: true xpack.security.http.ssl.verification_mode: certificate xpack.security.http.ssl.keystore.path: certs/elastic-node.p12 xpack.security.http.ssl.truststore.p
