Elasticsearch 9.x 如何安全修改内置用户（如 elastic）密码？

Question

在 Elasticsearch 9.x 中，内置用户（如 `elastic`）的密码**无法通过 Kibana UI 或 `_security/user/elastic` API 直接修改**，这是出于安全强化设计：9.x 默认启用安全功能且禁用不安全的密码重置路径。常见问题为管理员尝试使用旧版命令（如 `bin/elasticsearch-reset-password -u elastic`）失败，或误以为可通过 HTTP PUT 更新用户导致 `400 Bad Request`（因内置用户密码字段被系统锁定）。此外，若未提前配置 TLS 和 `xpack.security.http.ssl`，`elasticsearch-reset-password` 工具将报 SSL 连接拒绝；而忘记 `-i` 交互参数时，工具可能静默退出无提示。更隐蔽的风险是：在多节点集群中仅重置单个节点的密码，导致节点间通信认证失败、集群状态异常。因此，必须严格使用官方推荐的 `elasticsearch-reset-password -u elastic -i` 命令，并确保所有节点同步执行、TLS 配置完备、且操作前已备份 `elasticsearch.yml` 与证书——任何跳过安全校验的“快捷方式”都将破坏集群完整性。

Answer 1

```html

一、现象层：为什么 Kibana UI 和 REST API 无法修改 elastic 用户密码？

在 Elasticsearch 9.x 中，elastic 是预置的超级用户（built-in user），其凭证由安全子系统严格管控。Kibana 的「Stack Management → Users」界面已移除对内置用户的编辑入口；调用 PUT _security/user/elastic 会返回 400 Bad Request 并附带错误信息："Cannot modify built-in user [elastic]"。这是由 SecurityIndexManager 在请求解析阶段主动拦截所致，属于硬编码级防护，非配置可绕过。

二、机制层：Elasticsearch 9.x 安全模型的演进与设计约束

• 默认启用 xpack.security.enabled: true，且禁用所有非 TLS 加密的 HTTP 管理端点
• 内置用户（elastic, kibana_system, logstash_system）密码存储于 .security-7 系统索引中，但该索引仅支持通过专用工具写入
• _security/user API 仅允许创建/更新 application users 和 role mapping users，内置用户字段（如 password）被显式标记为 readonly
• TLS 成为强制前置条件：未配置 xpack.security.http.ssl.* 时，elasticsearch-reset-password 工具将因无法建立 HTTPS 连接而失败（报错：sun.security.provider.certpath.SunCertPathBuilderException）

三、操作层：正确重置密码的完整流程与关键校验点

1. ✅ 验证集群健康状态：GET /_cluster/health?pretty
2. ✅ 检查 TLS 配置完整性（必须包含 certificate, key, certificate_authorities）
3. ✅ 备份 elasticsearch.yml 及 config/certs/ 目录（含 http.p12, transport.p12）
4. ✅ 在每个节点上执行：bin/elasticsearch-reset-password -u elastic -i（-i 强制交互确认，避免静默退出）
5. ✅ 记录新密码并立即更新 Kibana 的 elasticsearch.username/elasticsearch.password 配置

四、风险层：典型误操作及其级联故障分析

误操作	直接后果	集群级影响
仅在一个节点执行 reset-password	该节点 elastic 密码变更，其余节点仍使用旧密码	节点间 transport 通信失败，cluster_state: RED，分片无法分配
省略 -i 参数	命令无任何输出即退出，管理员误判为成功	后续 Kibana 登录失败，但排查方向错误（如怀疑证书而非密码）
使用 curl PUT 修改密码	返回 400 + 明确拒绝提示	触发审计日志 security-audit.log 中高频 access_denied 事件

五、架构层：密码重置工具的底层执行逻辑（Mermaid 流程图）

%%{init: {'theme': 'base', 'themeVariables': { 'fontSize': '14px'}}}%%
flowchart TD
    A[启动 elasticsearch-reset-password] --> B{检查节点状态}
    B -->|未连接| C[报错：Unable to connect to Elasticsearch]
    B -->|已连接| D[验证 TLS 证书链有效性]
    D -->|失败| E[报错：SSLHandshakeException]
    D -->|成功| F[向 _security/credential/built_in_user/elastic 发起 POST]
    F --> G[Security Index 写入新哈希值]
    G --> H[广播 credential change event]
    H --> I[所有节点 reload 凭据缓存]

六、治理层：面向生产环境的密码生命周期管理建议

• 禁止将 elastic 密码用于应用直连——应创建具备最小权限的角色绑定用户
• 启用 xpack.security.authc.token.enabled: true 实现无密码 API 调用
• 定期轮换 elastic 密码（建议每 90 天），并配合自动化脚本同步更新 Kibana、Logstash、Beats 配置
• 将 elasticsearch-reset-password 命令封装为 Ansible Playbook，确保多节点原子性执行
• 审计日志中持续监控 connection_denied 和 authentication_failed 事件突增

```