Azure DevOps Pipeline中使用用户分配托管身份访问Azure SQL失败排查

核心问题分析 #

你遇到的两个错误对应不同的配置缺失：

• 带User Id时的400错误：用户分配托管身份（UMI）未被授予访问Azure SQL服务器的权限，或服务连接的联合凭据配置未正确传递UMI身份上下文。
• 移除User Id后的登录失败：应用默认使用的身份（非目标UMI）未在SQL数据库中创建对应的用户主体。

具体修复步骤 #

1. 补充服务器级别的UMI登录权限 #

仅创建数据库用户不足以让UMI访问SQL服务器，需要先创建服务器级登录：

CREATE LOGIN [myManagedIdentityUser] FROM EXTERNAL PROVIDER;

执行后，确保该登录与你已创建的数据库用户关联（数据库用户基于此服务器登录映射）。

2. 配置AzureCli@2任务的身份传递 #

在AzureCli@2任务中开启身份环境变量注入，确保应用能获取到UMI的凭据：

- task: AzureCli@2
  inputs:
    azureSubscription: '你的联合凭据服务连接名称'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: 'dotnet run 你的应用启动命令'
    addSpnToEnvironment: true

此配置会将UMI的ClientId等信息注入环境变量，应用可自动读取完成身份认证。

3. 修正连接字符串的User Id配置 #

使用UMI的Client Id作为连接字符串中的User Id值，这是多数SDK指定用户分配身份的标准方式：

Server=tcp:xxx-xxxxx-sql.database.windows.net,1433;Database=MYDB;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Authentication=Active Directory Managed Identity;User Id=你的UMI ClientId;

若开启了addSpnToEnvironment: true，应用也可自动读取环境变量AZURE_CLIENT_ID，此时可省略连接字符串中的User Id。

4. 验证UMI的Azure RBAC权限 #

在Azure门户中找到你的UMI，进入权限页面，确认已分配针对目标Azure SQL数据库的SQL DB Contributor角色（或包含Microsoft.Sql/servers/databases/*权限的自定义角色）。

5. 检查SQL服务器防火墙规则 #

确保Azure SQL服务器的防火墙规则允许Azure DevOps代理访问：

• 若使用微软托管代理：启用“允许Azure服务和资源访问此服务器”选项。
• 若使用自托管代理：添加代理的公网IP到防火墙规则中。

内容的提问来源于stack exchange，提问作者Alf Kåre Lefdal