Elasticsearch 9.1.0 默认禁用`elastic`用户密码登录，`changeme`不再生效

Question

**问题：** 升级或首次部署 Elasticsearch 9.1.0 后，尝试使用 `elastic` 用户配合默认密码 `changeme` 通过 HTTP Basic Auth 登录（如 Kibana 连接、curl 访问 `_cat/indices`），始终返回 `401 Unauthorized`。检查 `elasticsearch.yml` 未显式禁用安全功能，`xpack.security.enabled` 为 `true`（默认），且证书已自动生成。为何 `elastic:changeme` 不再可用？是否需手动重置密码？重置时是否仍可使用 `bin/elasticsearch-reset-password -u elastic`？该变更是否影响 TLS 配置或 FIPS 模式兼容性？

Answer 1

一、现象确认与默认行为变更溯源

自 Elasticsearch 8.0 起，安全功能（xpack.security.enabled）默认启用，但真正关键的转折点在 9.0.0 版本正式移除所有“内置默认凭据”的自动生效逻辑。Elasticsearch 9.1.0 不再为 elastic 用户预设或回退到 changeme 密码——该字符串仅作为安装向导提示（如 elasticsearch-setup-passwords 的交互式输出示例），绝不等同于实际生效密码。首次启动时若未显式初始化密码，系统将生成加密凭证并强制要求用户通过安全工具完成初始化。

二、安全凭证生命周期解析（含状态机）

graph LR A[ES 9.1.0 启动] --> B{是否已执行凭证初始化？} B -->|否| C[拒绝 HTTP Basic Auth
返回 401] B -->|是| D[验证 hash 匹配
允许访问] C --> E[必须调用 reset-password 或 setup-passwords] E --> F[凭证持久化至 security index
（.security-7）]

三、核心问题归因：三个不可逆设计决策

• ① 默认密码语义废弃：changeme 仅保留在文档和 CLI 提示中，不参与任何认证流程；ES 9.x 拒绝硬编码凭据，符合 NIST SP 800-63B “禁止默认凭证” 强制要求。
• ② 安全索引初始化前置：首次启动后，ES 自动创建 .security-7 索引并生成 elastic 用户的 bcrypt v4 哈希（非明文存储），但该哈希值初始为空或占位符，需人工触发初始化。
• ③ TLS 与身份认证解耦强化：即使配置了 xpack.security.http.ssl.*，HTTPS 仅保障传输层加密，不豁免应用层认证；证书自动生成（elasticsearch-certutil）仅解决 TLS，与用户密码无关。

四、实操验证路径与诊断命令表

场景	命令	预期输出（成功）	典型失败线索
检查安全索引状态	curl -k -u elastic:changeme https://localhost:9200/_cat/indices/.security*	.security-7 1 1 ...	401 + "error":"unable to authenticate"
验证用户是否存在	bin/elasticsearch-users list	elastic * (enabled)	报错 User 'elastic' does not exist（说明未初始化）

五、密码重置全流程（兼容性保障）

✅ bin/elasticsearch-reset-password -u elastic 在 9.1.0 中完全可用且推荐——它直接操作本地节点的 Keystore 和 Security Index，无需 Kibana 或 HTTP 访问权限。执行时需确保：

1. ES 进程已停止（热重置不支持）；
2. 使用与 ES 启动相同的用户权限运行命令；
3. 若启用 FIPS 模式（bootstrap.fips_mode: true），工具自动选用 FIPS-compliant bcrypt 实现（BCryptFIPS），不影响重置流程。

重置后新密码立即生效，且 TLS 配置（如 xpack.security.http.ssl.verification_mode: certificate）保持不变，FIPS 兼容性无降级风险。

六、升级迁移关键检查清单

• ▶️ 升级前：运行 bin/elasticsearch-migration 扫描遗留配置冲突（如旧版 authc realm 配置）；
• ▶️ 首次启动后：立即执行 bin/elasticsearch-reset-password -u elastic -i（交互式）或 -b（批量模式）；
• ▶️ Kibana 配置：更新 elasticsearch.username 和 elasticsearch.password，并确认 elasticsearch.ssl.verificationMode: "full" 与 ES 证书匹配；
• ▶️ 监控告警：检查日志中 security.authc.realms.native.native0 是否报告 user [elastic] authenticated。

七、高级陷阱：FIPS 模式下的特殊约束

当启用 FIPS（Federal Information Processing Standards）时，Elasticsearch 9.1.0 强制使用 Bouncy Castle FIPS-approved crypto provider。此时：所有密码哈希必须使用 FIPS-compliant BCrypt（cost=12），而 changeme 明文无法通过 FIPS 校验；elasticsearch-reset-password 内部自动适配，但手动 SQL/HTTP 插入哈希值将被拒绝。TLS 配置不受影响，但需确保 JVM 启动参数包含 -Dfips.mode=true 且 BCFIPS JAR 已加载。

八、架构级启示：零信任模型落地实践

Elasticsearch 9.x 将“默认安全”从配置开关升级为不可绕过的状态机：凭证初始化成为集群健康检查（_cluster/health?wait_for_status=yellow）的隐式依赖项。这意味着运维脚本必须将 reset-password 纳入 CI/CD 流水线（如 Ansible command 模块 + creates 条件判断），而非依赖人工干预。这种设计显著提升云原生环境合规性（SOC2, HIPAA），但也要求 SRE 团队重构部署范式——安全不再是“可选加固”，而是启动必经阶段。