KEDA Temporal Scaler 在 Temporal Cloud 中使用 API Key 认证的 TLS 配置问题分析

问题背景

KEDA（Kubernetes Event-driven Autoscaling）是一个流行的 Kubernetes 事件驱动自动扩展组件，其中的 Temporal Scaler 用于根据 Temporal 工作流引擎中的任务队列长度来自动扩展工作节点。然而，当用户尝试将 Temporal Scaler 与 Temporal Cloud 服务配合使用时，发现了一个关键的身份验证问题。

问题现象

用户在使用 Temporal Cloud 的 API Key 认证方式时，KEDA 的 Temporal Scaler 无法正常工作，系统日志显示连接错误："read: connection reset by peer"。经过分析，这是由于 Temporal Scaler 在与 Temporal Cloud 建立连接时没有正确启用 TLS 加密导致的。

技术分析

Temporal Cloud 的安全要求

Temporal Cloud 要求所有使用 API Key 认证的客户端连接都必须启用 TLS 加密。这是 Temporal Cloud 的安全策略之一，旨在确保所有通信都经过加密保护。

KEDA Temporal Scaler 的实现缺陷

在 KEDA 的 Temporal Scaler 实现中，当仅配置 API Key 认证时，代码没有自动启用 TLS 连接选项。这导致客户端尝试以明文方式连接 Temporal Cloud 服务，而服务器端由于安全策略会拒绝这种不安全的连接，从而产生"connection reset by peer"错误。

根本原因

查看 KEDA 源代码可以发现，Temporal Scaler 在处理 API Key 认证时，没有将 TLS 设置为默认启用状态。这与 Temporal Cloud 的安全要求相矛盾，导致了连接失败。

解决方案

临时解决方案

用户发现可以通过同时提供客户端证书的方式来强制启用 TLS 连接，即使不使用 mTLS（双向 TLS）认证：

1. 使用 Temporal Cloud CLI 工具生成 CA 证书和客户端证书
2. 将生成的客户端证书和私钥进行 Base64 编码
3. 将这些凭证添加到 Kubernetes Secret 中
4. 在 TriggerAuthentication 中同时配置 apiKey、cert 和 key 参数

这种方法虽然可行，但增加了不必要的证书管理复杂度。

理想解决方案

从技术实现角度，KEDA Temporal Scaler 应该进行以下改进：

1. 当检测到使用 Temporal Cloud 端点（包含 .temporal.io 域名）时，自动启用 TLS
2. 对于 API Key 认证方式，强制要求 TLS 连接
3. 提供明确的错误提示，指导用户正确配置 TLS

最佳实践建议

对于需要在生产环境中使用 KEDA Temporal Scaler 与 Temporal Cloud 集成的用户，建议：

1. 始终为 Temporal Cloud 连接启用 TLS
2. 定期轮换 API Key 和证书
3. 监控连接状态和自动扩展指标
4. 保持 KEDA 组件更新，以获取最新的安全修复和功能改进

总结

这个问题凸显了在云服务集成中安全配置的重要性。KEDA 作为连接 Kubernetes 和外部系统的桥梁，需要特别注意各种云服务的特定安全要求。开发者在使用类似集成时，应当仔细阅读目标服务的文档，了解其安全模型和连接要求，以避免类似的连接问题。