Elastic Cloud on Kubernetes (ECK) 中证书验证问题的深度解析与解决方案

在基于 Kubernetes 的 Elastic Cloud (ECK) 环境中部署监控体系时，证书验证问题是一个常见的技术挑战。本文将从架构设计角度剖析问题本质，并提供生产环境中的最佳实践方案。

问题现象分析

当用户通过 Elastic Agent 的 Kibana 集成进行监控时，会出现典型的证书验证失败错误：

x509: certificate signed by unknown authority

这表明 Agent 无法验证 Kibana 服务端证书的合法性，核心原因是 ECK 默认使用自签名证书，而 Agent 容器内未配置相应的 CA 证书信任链。

技术解决方案对比

方案一：禁用证书验证（临时方案）

在 Agent 配置中添加：

ssl.verification_mode: "none"

这种方案虽然简单，但会完全绕过 TLS 验证，存在中间人攻击风险，不建议在生产环境使用。

方案二：CA 证书注入（推荐方案）

正确做法是将 ECK 生成的 CA 证书挂载到 Agent 容器：

1. 从 Kibana 所在命名空间获取名为 kibana-prod-eck-kibana-kb-http-ca-internal 的 Secret
2. 将 ca.crt 挂载到 Agent 容器指定路径
3. 在集成配置中指定证书路径：

ssl.certificate_authorities: ["/path/to/ca.crt"]

监控架构选型建议

ECK 提供两种监控方案，各有适用场景：

内置监控方案

特点：

• 通过 spec.monitoring 配置指向监控集群
• 自动部署 Metricbeat 采集数据
• 支持跨集群监控
• 配置管理由 ECK 全托管

局限性：

• 无法自定义索引模板和 ILM 策略
• 监控数据路由策略固定

Elastic Agent 方案

优势：

• 完全掌控 Beat 配置
• 可自定义索引生命周期管理
• 灵活配置数据路由规则 示例配置：

setup.ilm:
  enabled: true
  policy_name: custom-policy
setup.template.settings:
  index:
    routing.allocation.require.type: "monitoring"

生产环境实践建议

1. 证书管理：为生产环境配置可信证书而非自签名证书，可通过 Cert Manager 实现自动签发

2. 监控架构：

• 中小规模部署：使用内置监控方案简化运维
• 大规模生产环境：采用 Elastic Agent 方案实现精细控制

3. 数据隔离：通过节点亲和性规则将监控数据存储在专用节点

nodeSelector:
  node-role.kubernetes.io/monitoring: ""

4. Agent 监控：确保 Fleet 集成中启用以下配置：

agent.monitoring:
  enabled: true
  metrics: true
  logs: true

总结

在 ECK 环境中处理证书问题时，理解底层证书信任机制是关键。对于需要高度定制化的生产环境，推荐采用 Elastic Agent 方案配合正确的证书管理方式，既能保证安全性，又能满足定制化需求。随着 ECK 的版本演进，建议持续关注其监控功能的增强，特别是对自定义索引管理的支持改进。