KEDA 使用 AWS Secrets Manager 认证问题的分析与解决

问题背景

在使用 KEDA 2.14.0 版本与 Kubernetes 1.29 集群时，开发团队遇到了一个关于 AWS Secrets Manager 认证的问题。具体表现为 KEDA 的 TriggerAuth 资源无法正确读取 AWS Secrets Manager 中存储的密钥，尽管配置了正确的 secretName 和 secret 参数。

问题现象

团队配置了一个 TriggerAuthentication 资源，希望通过 AWS Secrets Manager 获取 Kafka 连接所需的认证凭证。配置如下：

apiVersion: v1
kind: TriggerAuthentication
metadata:
  name: test-triggerauth
  namespace: my-microservice-namespace
spec:
  awsSecretManager:
    podIdentity:
      provider: aws
      roleArn: arn:aws:iam::<accountId>:test-role/<test-role-ID>
    region: us-east-1
    secrets:
    - name: service/test-svc/svc-api-key-path
      parameter: api-key
    - name: service/test-svc/svc-api-key-path
      parameter: api-secret

目标 Secrets Manager 中的密钥格式为 JSON 结构：

{
  "api-key":"MY-SECRET-KEY",
  "api-secret":"MY-SECRET--VAL"
}

错误表现

KEDA 操作日志显示认证参数解析失败，具体错误为 Kafka 客户端无法连接到代理。虽然错误表面上是连接问题，但根本原因在于认证凭据未能正确获取。

排查过程

1. 验证密钥存在性：确认密钥确实存在于指定的 AWS 区域和 Secrets Manager 中
2. 检查 IAM 权限：验证了 KEDA 操作员使用的 IAM 角色具有访问 Secrets Manager 的权限
3. 检查环境变量：确认 KEDA 操作员 Pod 中已正确设置 AWS 相关环境变量
4. 检查网络连接：排除了网络连接问题导致的可能性

解决方案

团队最终通过以下方式解决了问题：

1. 使用 Secrets Store CSI 驱动：配置了一个 AWS Secrets Provider Class 来从 Secrets Manager 读取密钥
2. 动态创建 Kubernetes Secret：让 CSI 驱动自动创建标准的 Kubernetes Secret 资源
3. 改用 ClusterTriggerAuth：使用 ClusterTriggerAuth 资源来引用这些动态创建的 Secret

这种解决方案的优势在于：

• 将密钥管理逻辑与 KEDA 解耦
• 可以利用 Kubernetes 原生的 Secret 资源
• 更符合云原生应用的安全实践

经验总结

1. 对于复杂的密钥管理场景，直接使用 AWS Secrets Manager 与 KEDA 集成可能不是最佳选择
2. 通过中间层（如 Secrets Store CSI 驱动）可以增加灵活性和可维护性
3. ClusterTriggerAuth 相比 TriggerAuth 在某些场景下可能更可靠
4. 密钥管理问题可能表现为其他组件（如 Kafka 客户端）的连接错误，需要仔细排查

最佳实践建议

1. 对于生产环境，考虑使用专门的密钥管理解决方案（如 Vault 或 AWS Secrets Manager）
2. 通过中间层抽象密钥获取逻辑，而不是让应用或 KEDA 直接访问密钥存储
3. 实施最小权限原则，严格控制 IAM 角色的权限范围
4. 定期轮换密钥并监控密钥访问情况

通过这次问题排查，团队不仅解决了当前的技术障碍，还建立了更健壮的密钥管理架构，为未来的扩展和维护打下了良好基础。