4. Kubecost 自身证书管理：UI 与 Prometheus 之间的 TLS 证书配置
在 Kubecost 架构中，前端 UI 与后端 Prometheus 之间的通信链路是成本数据采集与展示的核心通道。默认情况下，Kubecost 会为 Prometheus 生成自签名证书以启用 TLS 加密，但在生产环境中，这种默认配置存在证书轮换不及时、权限泄露等风险。本章将深入分析该链路的证书管理机制、配置方法及安全审计要点。
4.1 通信链路与证书角色
Kubecost UI 通过 Kubecost Cost-Analyzer 服务间接访问 Prometheus 数据。整个链路涉及两个关键 TLS 端点：
- Prometheus Server：对外暴露 HTTPS 端口（默认 9090），提供指标查询接口。
- Kubecost Cost-Analyzer：作为反向代理，将 UI 请求转发至 Prometheus，并验证 Prometheus 的服务端证书。
证书在此链路中承担双重职责：
- 身份验证：确保 UI 连接的是合法的 Prometheus 实例，防止中间人攻击。
- 传输加密：保护成本指标、标签、命名空间等敏感数据在传输过程中不被窃听。
审计要点： 如果 Prometheus 证书由 Kubecost 自动生成且未配置轮换策略，证书过期后将导致 UI 无法获取成本数据，形成“静默故障”——用户看到的是空白仪表盘，而非明确的错误提示。
4.2 默认证书生成与存储
Kubecost 在安装时通过 Helm Chart 的 prometheus.server.tls 配置段控制证书行为。默认情况下，Kubecost 会生成一个自签名证书并存储在 Kubernetes Secret 中：
| 资源类型 | 名称 | 命名空间 | 关键字段 |
|---|---|---|---|
| Secret | kubecost-prometheus-server-tls |
kubecost |
tls.crt, tls.key |
| ConfigMap | kubecost-prometheus-server |
kubecost |
prometheus.yml 中的 tls_server_config |
默认证书的有效期通常为 365 天，且 Kubecost 不会自动轮换该证书。这意味着在部署一年后，如果没有手动干预，UI 与 Prometheus 之间的 TLS 握手将失败。
4.3 证书轮换配置步骤
为了消除证书过期风险，建议在生产环境中使用 cert-manager 或手动轮换策略。以下是基于 cert-manager 的推荐配置流程：
- 创建 Issuer/ClusterIssuer：定义证书颁发机构（如 Let's Encrypt 或内部 CA）。
- 创建 Certificate 资源：指定 DNS 名称（如
prometheus.kubecost.svc.cluster.local）和 Secret 名称。 - 更新 Prometheus 配置：修改
prometheus.yml中的tls_server_config指向新证书路径。 - 重启 Prometheus：使新证书生效。
- 验证连接：通过
curl --cacert测试 UI 到 Prometheus 的 TLS 握手。
权限变更风险： 在轮换证书时，如果 Secret 的访问权限（RBAC）未同步更新，Kubecost Cost-Analyzer 可能因无法读取新 Secret 而拒绝启动。审计时应检查
RoleBinding 是否包含对 kubecost-prometheus-server-tls 的 get 和 watch 权限。
4.4 证书配置参数对比
以下表格对比了默认自签名证书与 cert-manager 管理证书的关键差异：
| 维度 | 默认自签名证书 | cert-manager 管理证书 |
|---|---|---|
| 有效期 | 365 天（固定） | 可配置（如 90 天） |
| 自动轮换 | 不支持 | 支持（到期前 30 天自动续期） |
| CA 验证 | 无（浏览器/客户端需跳过验证） | 支持（可配置信任链） |
| 审计日志 | 无 | cert-manager 提供事件日志 |
| 轮换风险 | 高（手动操作易出错） | 低（自动化流程） |
4.5 证书轮换流程示意图
下图展示了从证书生成到 UI 验证的完整数据流，以及轮换操作的关键节点：
4.6 安全审计检查清单
在进行 Kubecost 证书安全审计时，建议逐项检查以下内容：
- 证书有效期：使用
openssl x509 -in tls.crt -text -noout | grep -A2 Validity检查剩余天数。 - 证书颁发者：确认是否使用内部 CA 而非自签名，避免浏览器/客户端警告。
- Secret 权限：检查
kubectl get rolebinding -n kubecost -o yaml中是否包含对 TLS Secret 的访问权限。 - 自动轮换配置：确认 cert-manager 的
Certificate资源中renewBefore字段是否设置（建议 720h）。 - Prometheus 配置：验证
prometheus.yml中的tls_server_config是否指向正确的证书路径。
最佳实践： 在 Kubecost 的 Helm values 中设置
prometheus.server.tls.enabled: true 并配合 prometheus.server.tls.existingSecret: "kubecost-prometheus-server-tls"，可以避免直接管理证书文件，将证书生命周期完全交给 cert-manager 处理。
4.7 常见故障与排查
| 故障现象 | 可能原因 | 排查命令 |
|---|---|---|
| UI 显示“No data” | 证书过期，Cost-Analyzer 无法连接 Prometheus | kubectl logs -n kubecost deployment/kubecost-cost-analyzer | grep -i tls |
| Prometheus 启动失败 | 证书文件权限错误或路径不匹配 | kubectl describe pod -n kubecost prometheus-server-xxx | grep -A5 Mounts |
| cert-manager 证书未续期 | Issuer 配置错误或网络不通 | kubectl describe certificate -n kubecost kubecost-prometheus-tls |
通过以上配置与审计措施，可以确保 Kubecost UI 与 Prometheus 之间的 TLS 通信始终处于安全、可靠的状态，避免因证书管理不当导致的成本数据中断或权限泄露风险。