KEDA 与 AWS Secrets Manager 集成中的 Pod Identity 权限问题解析

背景介绍

KEDA (Kubernetes Event-driven Autoscaling) 是一个流行的 Kubernetes 事件驱动自动伸缩工具。在实际生产环境中，很多用户会将其与 AWS Secrets Manager 集成，用于安全地获取数据库凭证等敏感信息。然而，在跨账户或精细权限控制的场景下，KEDA 与 AWS Secrets Manager 的集成曾存在一个关键权限问题。

问题本质

问题的核心在于 KEDA 操作员在访问 AWS Secrets Manager 时，未能正确遵循 TriggerAuthentication 资源中配置的 Pod Identity 角色设置。具体表现为：

1. 当配置了 awsSecretManager.podIdentity.roleArn 时，KEDA 仍然使用操作员自身的 IAM 角色
2. 当设置 awsSecretManager.identityOwner.workload 时，KEDA 未正确使用工作负载 Pod 关联的 IAM 角色

技术细节分析

这个问题涉及 Kubernetes 与 AWS IAM 的深度集成机制。在理想情况下，KEDA 应该能够：

• 根据 TriggerAuthentication 配置，动态承担指定的 IAM 角色
• 或者继承工作负载 Pod 的 IAM 身份来访问 Secrets Manager

但在 2.15.1 及更早版本中，这一机制存在缺陷，导致 KEDA 始终使用其操作员 Pod 的 IAM 角色进行 Secrets Manager 访问，从而在跨账户场景下产生权限拒绝错误。

解决方案与版本演进

经过社区验证，这个问题在 KEDA 2.16.1 和 2.17 版本中得到了根本解决：

1. 2.16.1 版本：修复了 Pod Identity 角色承担机制，KEDA 开始能够正确识别并使用工作负载 Pod 的 IAM 身份
2. 2.17 版本：进一步增强了 Secrets Manager 集成，支持了 secretKey 字段，允许从单个 Secrets Manager 条目中提取多个键值

最佳实践配置

基于修复后的版本，推荐以下配置方式：

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: secure-auth
spec:
  awsSecretManager:
    podIdentity:
      provider: aws
      identityOwner: workload  # 使用工作负载Pod的IAM角色
    region: us-east-1
    secrets:
    - parameter: username
      name: db-credentials
      secretKey: username  # 从Secrets Manager条目中提取特定键
    - parameter: password
      name: db-credentials
      secretKey: password

实施建议

对于需要集成 KEDA 与 AWS Secrets Manager 的用户，建议：

1. 确保使用 KEDA 2.16.1 或更高版本，推荐直接采用 2.17+ 版本
2. 在跨账户场景下，正确配置工作负载 Pod 的 IAM 角色及信任关系
3. 利用 secretKey 特性简化 Secrets Manager 条目管理
4. 在生产部署前充分测试权限配置

总结

KEDA 与 AWS Secrets Manager 的集成在较新版本中已经具备了完善的 Pod Identity 支持，能够满足企业级的安全与权限隔离需求。通过正确配置，可以实现细粒度的访问控制，确保自动伸缩组件既能安全获取所需凭证，又遵循最小权限原则。