Elastic Cloud on Kubernetes (ECK) 中 Fleet Server 401 认证错误分析与解决方案

问题背景

在使用 Elastic Cloud on Kubernetes (ECK) 2.16 版本部署时，用户遇到了 Fleet Server 无法正常启动的问题。错误日志显示 Fleet Server 在尝试访问 Kibana API 时返回了 401 未授权状态码。该部署环境基于 Kubernetes 1.30 运行在 Azure Kubernetes Service (AKS) 上，镜像存储在 Azure 容器注册表中。

错误现象

当 ECK Operator 尝试启动 Fleet Server 时，控制器日志中出现了以下关键错误信息：

failed to request https://kibana-kb-http.elkstack.svc:5601/api/fleet/setup, status is 401

这表明 Fleet Server 在初始化过程中无法通过 Kibana API 的身份验证。

根本原因分析

经过深入排查，发现问题的核心在于认证配置的缺失。在 ECK 部署中，Fleet 及其相关组件（包括 Fleet Server 和 Elastic Agents）需要明确启用基础认证（Basic Authentication）机制。当认证配置不完整或缺失时，组件间的 API 通信就会因缺乏有效的身份凭证而被拒绝。

值得注意的是，错误信息虽然指向 Kibana API，但实际上反映了整个认证链路的配置问题，而不仅仅是 Kibana 端的设置。

解决方案

要解决此问题，需要在部署配置中明确启用并正确配置基础认证。以下是关键配置要点：

1. 确保 Elasticsearch 和 Kibana 启用了安全特性：在 StackConfigPolicy 或集群配置中，需要包含适当的安全设置。

2. 验证服务账户权限：确保为 Elastic Agent 配置的服务账户具有足够的权限访问所需资源。

3. 检查网络策略：确认组件间的网络通信没有被网络策略意外阻断。

配置建议

对于生产环境部署，建议采用以下最佳实践：

1. 使用明确的版本标签而非 "latest" 来指定软件包版本，确保部署的可预测性。

2. 为不同环境（如开发、测试、生产）配置独立的命名空间和资源标签。

3. 定期轮换凭据和证书，遵循安全最佳实践。

经验总结

这个案例提醒我们，在 ECK 部署中，安全配置是不可或缺的一环。特别是在涉及多个组件交互的场景下（如 Fleet Server 与 Kibana 的通信），必须确保认证机制的完整性和一致性。开发者在遇到类似 401 错误时，应当首先检查认证相关的配置项，而不是仅关注表面错误信息指示的组件。

后续改进

Elastic 官方文档应当更明确地强调 Fleet 相关组件对基础认证的强制性要求，避免其他用户遇到类似问题。同时，错误信息可以进一步优化，提供更明确的认证失败原因指引，帮助用户更快定位问题根源。