Elasticsearch设置密码实战：从零构建安全的ELK日志平台
你有没有遇到过这样的场景？某天早上刚到公司，运维群里突然弹出一条告警——“我们的Elasticsearch集群被植入了勒索病毒，所有数据已被加密，请支付0.5 BTC解密”。点开ES控制台一看，果然首页变成了黑色背景加红色大字。再查访问日志，发现外网IP直接通过9200端口写入了恶意文档。
这不是段子，而是真实发生过的安全事故。
在今天的企业环境中，Elastic Stack（即ELK：Elasticsearch + Logstash + Kibana）几乎成了日志分析的标准配置。但很多人只关注功能部署，却忽略了最基础的一环：安全加固。默认安装的Elasticsearch就像一扇没上锁的大门，任何人都能随意进出。
本文将带你一步步完成Elasticsearch 设置密码的完整流程，不讲空话，只说实战中踩过的坑和真正有效的解决方案。
为什么必须为Elasticsearch设置密码？
我们先看一组数据：
- 据Shodan扫描显示，全球有超过10万个Elasticsearch节点暴露在公网；
- 其中超过60%未启用任何身份认证；
- 平均每37秒就有一台ES节点遭受暴力破解攻击。
而这一切的起点，往往只是因为xpack.security.enabled还是false。
不设密码的风险远不止数据泄露：
- 攻击者可以删除或篡改索引；
- 利用集群资源挖矿；
- 上传Webshell反向控制服务器；
- 甚至作为跳板入侵内网其他系统。
所以，Elasticsearch设置密码不是“可选项”，而是上线前的强制动作。
安全机制核心组件解析
从6.8版本开始，Elasticsearch内置了X-Pack Security模块的基础功能，免费提供以下能力：
| 功能 | 说明 |
|---|---|
| 用户认证 | 支持用户名/密码、API Key等 |
| 角色权限控制（RBAC） | 细粒度分配读写权限 |
| TLS加密通信 | 防止中间人攻击 |
| 审计日志 | 记录登录尝试与敏感操作 |
其中最关键的第一步就是启用用户认证，也就是我们常说的“设密码”。
内置账户有哪些？各自用途是什么？
Elasticsearch会自动创建几个专用系统账户，它们不是给你日常使用的，而是供各组件内部通信使用：
| 用户名 | 所属组件 | 权限范围 |
|---|---|---|
elastic | 超级管理员 | 全部权限，慎用！ |
kibana_system | Kibana | 仅允许Kibana相关API调用 |
logstash_system | Logstash | 写入监控指标 |
beats_system | Filebeat等Beats | 上报心跳与状态 |
apm_system | APM Server | APM数据写入 |
⚠️ 注意：不要把这些账号当作普通用户使用。生产环境应为不同角色创建独立账户，遵循最小权限原则。
实战第一步：启用安全功能并生成证书
修改配置文件
编辑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: certs/elastic-certificates.p12 xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12 # 启用HTTP层TLS（客户端访问） xpack.security.http.ssl.enabled: true xpack.security.http.ssl.keystore.path: certs/http.p12📌 提示：如果你的节点分布在多个主机上，确保所有节点使用相同的证书文件，否则会出现信任问题。
自动生成证书（推荐方式）
Elasticsearch自带工具elasticsearch-certutil可以快速生成所需证书。
1. 生成CA证书
./bin/elasticsearch-certutil ca --out config/certs/ca.p12 --pass ""执行后会生成一个名为ca.p12的CA证书。
2. 签发节点证书
./bin/elasticsearch-certutil cert --ca config/certs/ca.p12 \ --out config/certs/elastic-certificates.p12 --pass ""这个命令会基于刚才的CA签发一套适用于所有节点的证书，并打包成PKCS#12格式。
3. 提取HTTP层证书（用于Kibana连接）
由于Kibana需要的是标准PEM格式证书，我们需要从中提取出来：
# 先导出pem openssl pkcs12 -in config/certs/http.p12 -out config/certs/http_ca.crt -nokeys -clcerts然后把http_ca.crt复制到Kibana服务器上的指定路径（如/etc/kibana/certs/）。
实战第二步：正式设置密码！
启动Elasticsearch服务：
systemctl start elasticsearch等待集群状态变为green或至少yellow后，执行密码初始化命令。
方式一：交互式设置（适合新手）
./bin/elasticsearch-setup-passwords interactive你会看到类似输出：
Initiating the setup of passwords for reserved users elastic, kibana_system, logstash_system, beats_system, apm_system, remote_monitoring_user. You will be prompted to enter passwords as the process progresses. Please confirm that you would like to continue [y/N]y Enter password for [elastic]: Reenter password for [elastic]: Enter password for [kibana_system]: Reenter password for [kibana_system]: ...建议规则：
- 至少8位；
- 包含大小写字母、数字、特殊字符；
- 不要使用常见单词或日期。
记录好每个用户的密码，尤其是elastic，这是后续管理的“万能钥匙”。
方式二：自动化脚本模式（适合CI/CD）
对于自动化部署环境，可以预先定义密码文件：
// passwords.json { "bootstrap_password": "InitPass123!", "cluster_admin": { "password": "AdminPass!2025" }, "kibana_system": { "password": "Kibana@123" }, "logstash_system": { "password": "Logstash#2025" } }然后运行：
./bin/elasticsearch-setup-passwords auto --batch --stdin < passwords.json注意：auto模式通常会忽略你传入的密码而自动生成随机强密码。若想强制使用预设值，需配合-s参数或修改安全策略。
配置Kibana连接认证
现在Elasticsearch已经上了锁，Kibana也得“拿钥匙进门”。
编辑config/kibana.yml：
# ES地址列表（必须使用HTTPS） elasticsearch.hosts: ["https://es-node1.example.com:9200"] # CA证书路径（验证服务端身份） elasticsearch.ssl.certificateAuthorities: ["/etc/kibana/certs/http_ca.crt"] # 使用系统账户连接 elasticsearch.username: "kibana_system" elasticsearch.password: "Kibana@123" # 加密存储密钥（防止敏感信息明文存储） encryptedSavedObjects.encryptionKey: "a_long_random_string_of_32_chars_xxx"🔐 最佳实践：避免在配置文件中硬编码密码。容器化部署时可通过环境变量注入：
yaml elasticsearch.password: ${KIBANA_ES_PASSWORD}并在启动时通过Docker Secrets或K8s Secret传递实际值。
重启Kibana：
systemctl restart kibana打开浏览器访问https://your-kibana:5601，如果能看到登录界面，说明连接成功！
Beats 和 Logstash 怎么办？
别忘了，Filebeat、Metricbeat这些采集器也要更新配置才能继续写入数据。
Filebeat 输出配置示例
output.elasticsearch: hosts: ["https://es-node1:9200"] username: "beats_system" password: "BeatsPass#2025" ssl.certificate_authorities: ["/etc/filebeat/certs/http_ca.crt"]Logstash 输出插件配置
output { elasticsearch { hosts => ["https://es-node1:9200"] user => "logstash_system" password => "Logstash#2025" ssl => true cacert => "/etc/logstash/certs/http_ca.crt" } }💡 小技巧：可以用
_security/_authenticateAPI 测试凭据是否有效：
bash curl -u kibana_system:Kibana@123 https://localhost:9200/_security/_authenticate?pretty成功返回包含当前用户信息的JSON，证明认证通过。
常见问题排查指南
❌ 报错：“Connection refused” when running setup-passwords
原因：Elasticsearch未正常启动。
检查项：
- 日志路径logs/elasticsearch.log是否有错误？
-network.host是否绑定到了0.0.0.0或正确内网IP？
- 防火墙是否放行了9200和9300端口？
- 如果启用了TLS，确认HTTP端口确实是9200而非8080。
❌ Kibana提示“No living connections”
典型症状：页面加载失败，后台日志出现SSL handshake failed。
解决步骤：
1. 用curl手动测试连接：bash curl -u kibana_system:Kibana@123 --cacert /etc/kibana/certs/http_ca.crt https://localhost:9200
2. 若失败，检查证书是否匹配；
3. 若成功，可能是Kibana配置路径错误或权限不足。
❌ 忘记了elastic用户密码怎么办？
别慌，官方提供了重置工具：
./bin/elasticsearch-reset-password -u elastic -i该命令可在节点停止状态下运行（离线模式），无需集群在线即可重置密码。
⚠️ 注意：此操作需要访问节点服务器权限，属于应急手段，不应频繁使用。
生产环境设计建议
1. 密码策略强化
在elasticsearch.yml中添加：
# 启用复杂度校验 xpack.security.authc.password_policy.length.min: 8 xpack.security.authc.password_policy.character_categories.min: 3要求密码至少包含三类字符（小写、大写、数字、特殊符号中的三种）。
2. 最小权限原则落地
不要让Filebeat用elastic账号跑！应该为其创建专用用户：
# 创建角色 POST _security/role/beats_writer { "indices": [ { "names": [ "filebeat-*", "metricbeat-*" ], "privileges": [ "create_index", "write", "read" ] } ] } # 创建用户 PUT _security/user/filebeat_internal { "password": "StrongPass!2025", "roles": [ "beats_writer" ] }然后在Beat配置中使用新账户。
3. 审计日志开启（合规刚需）
# elasticsearch.yml xpack.security.audit.enabled: true xpack.security.audit.log.events.include: access_denied, authentication_failed审计日志会记录每一次失败的登录尝试，可用于事后追溯和攻击分析。
4. 升级前备份关键文件
升级Elasticsearch前务必备份：
-config/certs/目录下的所有证书；
-config/users和config/users_roles（如果是文件方式存储）；
- 当前的elasticsearch.yml和kibana.yml。
新版可能更改默认行为，例如7.10+强制要求HTTPS。
写在最后：安全是一场持续战
完成Elasticsearch设置密码只是安全建设的第一步。真正的挑战在于长期维护：
- 定期轮换高权限账户密码；
- 监控异常登录行为；
- 结合LDAP/AD实现统一身份管理；
- 使用API Key替代长期有效的密码；
- 在云环境中集成IAM角色授权。
记住一句话：没有绝对的安全，只有持续的防护。
当你完成了这次密码设置，不妨顺手做一件事——用Shodan搜索一下自己的公网IP，看看还有没有其他服务暴露在外。也许你会发现，除了ES，Redis、MongoDB也都开着门等你来锁。
如果你正在搭建或维护一个Elastic Stack平台，欢迎在评论区分享你的安全实践方案。我们一起把这扇门关得更牢一点。
