KEDA 中使用 Azure Workload Identity 认证 Service Bus 的问题解析

问题背景

在使用 KEDA 进行 Azure Service Bus 队列自动伸缩时，许多开发者选择采用 Azure AD Workload Identity 作为认证方式。这种认证模式相比传统的密钥认证更加安全，但在实际部署过程中可能会遇到一些配置上的挑战。

典型错误现象

当配置不当时，KEDA 操作器会报告以下两类关键错误：

1. 凭证源错误：sources must contain at least one TokenCredential，表明系统未能正确获取到有效的令牌凭证。

2. 令牌文件路径错误：no token file specified. Check pod configuration or set TokenFilePath in the options，这通常意味着 Workload Identity 注入的卷挂载或环境变量未能正确配置。

核心配置要点

1. TriggerAuthentication 配置

在 TriggerAuthentication 资源中，必须正确指定 Workload Identity 的客户端 ID：

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: app-keda
spec:
  podIdentity:
    provider: azure-workload
    identityId: <your-managed-identity-client-id>

2. 权限分配

确保托管身份已被授予适当的 Azure Service Bus 数据权限。典型角色分配应包括：

• Azure Service Bus Data Owner 或 Azure Service Bus Data Receiver 角色
• 作用域精确到队列级别：bus-demo-gitops/gitopsqueue

深度排查指南

环境变量验证

KEDA 操作器 Pod 必须包含 Workload Identity 注入的以下关键环境变量：

• AZURE_CLIENT_ID：托管身份的客户端ID
• AZURE_TENANT_ID：Azure租户ID
• AZURE_FEDERATED_TOKEN_FILE：令牌文件路径
• AZURE_AUTHORITY_HOST：认证终结点

常见配置误区

1. 身份联邦关系不完整：确保在托管身份中正确配置了与AKS集群OIDC的联邦凭据。

2. 服务账户注解缺失：KEDA操作器部署使用的服务账户需要包含正确的注解：

   annotations:
     azure.workload.identity/client-id: <managed-identity-client-id>
   

3. 令牌文件挂载问题：检查Pod中/var/run/secrets/azure/tokens目录是否包含有效的令牌文件。

解决方案实施

1. 重启KEDA操作器：在确认所有配置正确后，重启操作器Pod以确保环境变量和卷挂载生效。

2. 日志分析：详细检查KEDA操作器和metrics-apiserver的日志，寻找更具体的错误线索。

3. 版本兼容性：确认KEDA版本(如2.14.0)与Kubernetes版本(如1.28)的兼容性。

最佳实践建议

1. 最小权限原则：仅授予托管身份必要的Service Bus权限。

2. 测试验证：先使用简单的ScaledObject配置测试基础认证是否通过，再逐步添加复杂规则。

3. 监控设置：配置适当的监控和告警，及时发现认证问题。

通过系统性地检查这些关键点，大多数Workload Identity认证问题都能得到有效解决。这种认证方式虽然初始配置较为复杂，但提供了比传统密钥更安全的长期解决方案。