开启Xpack安全的EFK栈ES pod重启后elastic用户认证失败如何解决

elastic用户认证401报错根因 #

• 未将ES内置用户的密码做持久化配置：ES集群首次启动时自动生成的elastic用户密码如果没有显式设置固定值，也没有存储在持久化的data目录中，pod重启时如果PVC挂载异常、或者使用了非持久化存储，内置用户的密码会被重置，Kibana中配置的旧密码自然无法通过校验。
• 组件配置不同步：如果使用自动生成凭证的部署方式，未将elastic用户的密码同步存储在K8s Secret中供Kibana读取，ES重启后新生成的凭证和Kibana本地存储的旧凭证不匹配，也会触发认证失败。

传输层异常报错根因 #

仅开启了xpack.security.transport.ssl.enabled开关，未同步配置SSL证书、密钥以及集群节点的信任链，ES节点之间传输通信时无法完成SSL握手，就会触发连接断开的警告。

1. 修复elastic用户认证问题 #

• 显式配置固定的elastic用户密码，不要依赖ES自动生成的随机密码。可通过ES的环境变量ELASTIC_PASSWORD在集群启动时指定固定值，密码需存储在K8s Secret中，禁止明文写在部署配置里。
• 确保Kibana配置中的elasticsearch.username、elasticsearch.password和你设置的elastic密码完全一致，密码从同一个Secret中读取，避免配置不同步。
• 确认ES集群的data目录使用了持久化PVC存储，不会因为pod重启被清空，避免内置用户的权限配置丢失。
• 如果使用Elastic官方Helm chart部署，直接在values.yaml中配置security.elasticPassword字段并开启security.enabled即可，chart会自动完成密码在各组件之间的同步。

2. 修复传输层SSL报错问题 #

• 除了开启xpack.security.transport.ssl.enabled: true之外，还需要补充如下传输层SSL配置：

xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12

• 提前生成集群通用的SSL证书，将证书存储在K8s Secret中，挂载到所有ES节点的对应目录下，保证所有节点使用同一份证书文件，避免信任校验失败。
• 暂时不需要节点通信加密的话，可以先关闭xpack.security.transport.ssl.enabled，先确认认证问题修复后再逐步配置传输层加密，避免多问题叠加提升排查难度。

手动删除任意一个ES pod等待重启完成后，执行kubectl exec -it <kibana-pod名称> -- curl -u elastic:<你设置的密码> http://<elasticsearch-svc名称>:9200，如果返回正常的集群信息则说明认证问题修复完成。确认Kibana日志无401报错、ES主节点日志无传输层异常警告，即所有问题解决。

内容的提问来源于stack exchange，提问作者balu