KEDA SQL Server触发器无法通过Azure服务主体登录Azure SQL数据库

核心问题 #

KEDA的MSSQL触发器依赖的Go语言SQL驱动，对Azure AD服务主体身份验证的参数处理逻辑，与应用使用的驱动（如.NET SqlClient）存在差异，导致相同连接串在KEDA中无法正常登录。

方案1：调整连接串参数 #

• 移除TrustServerCertificate=True：Azure SQL的证书验证逻辑在KEDA驱动中与该参数存在冲突，而应用驱动对该参数的兼容性更强
• 确保Authentication参数严格匹配ActiveDirectoryServicePrincipal（大小写敏感）
• 更新后的连接串创建命令：

kubectl create secret generic my-mssql-secrets --from-literal mssql-connection-string="server=azuse2sqlmixxxxx.xxxxxxx.database.windows.net;Authentication=ActiveDirectoryServicePrincipal;Initial Catalog=yyyyyy;User Id=99775ec3-xxxxxx-xxxx-xxx;Password=xxxxxxxx;Persist Security Info=False;Encrypt=True;"

方案2：改用Azure AD托管身份 #

托管身份无需管理密码，且与KEDA的兼容性更稳定：

1. 为KEDA Operator所在的Pod启用系统分配托管身份或用户分配托管身份
2. 在Azure SQL中，将该托管身份添加为AD用户，并授予db_datareader权限（至少需要读取触发器查询对象的权限）
3. 简化连接串：

kubectl create secret generic my-mssql-secrets --from-literal mssql-connection-string="server=azuse2sqlmixxxxx.xxxxxxx.database.windows.net;Authentication=ActiveDirectoryMSI;Initial Catalog=yyyyyy;Encrypt=True;"

4. 保持原有的TriggerAuthentication和ScaledObject配置不变

方案3：临时过渡方案——SQL身份验证 #

如果上述方案无法快速落地，可继续使用SQL身份验证：

1. 创建拥有db_datareader权限的SQL登录用户
2. 更新连接串为SQL auth格式：

kubectl create secret generic my-mssql-secrets --from-literal mssql-connection-string="server=azuse2sqlmixxxxx.xxxxxxx.database.windows.net;Initial Catalog=yyyyyy;User Id=sql_user;Password=sql_password;Persist Security Info=False;Encrypt=True;"

额外排查要点 #

• 验证服务主体权限：确认该SP已被添加到Azure SQL的AD用户列表，且拥有触发器查询所需的最小权限（如db_datareader）
• 检查KEDA版本：使用KEDA 2.8.0及以上版本，旧版本存在Azure AD身份验证的兼容性问题
• 查看KEDA Operator日志：执行kubectl logs -n keda deployment/keda-operator，获取更详细的错误栈，排查网络或权限细节

内容的提问来源于stack exchange，提问作者Tapas P