我有一个 ASP.Net Core 2.1 项目，其中包含一些集成测试，这些测试项目需要/需要 Azure 托管服务标识访问才能成功运行（从 KeyVault 获取机密）。我正在使用 Azure DevOps VS2017 Hosted Build Agent 来构建项目以部署到 Azure 应用服务。我遇到的问题是，当测试在构建管道之后运行时，它们会失败，因为 MSI 访问在托管的构建代理上不可用。如何设置托管构建代理所需的适当 MSI 访问？是否可以通过 Powershell 任务或类似的东西来做到这一点？
谢谢！
退后一步，您可能已经知道这一点，但只是为了解释一下我的思考过程：
想想托管服务标识只是您不知道密码的服务主体（即服务帐户），而且用户是为您创建并由 Microsoft 管理的。
因此，从这个意义上说，只要您通过托管代理可以承担其身份的密钥库访问策略授予服务主体访问权限，您就会被排序。
有好消息也有坏消息。好消息是，托管代理至少在使用 Azure PowerShell 任务时配备了服务主体，就像 MSI，您不知道密码（除非您添加密码），但它们会为您预先登录。
在“阶段”设置中，您可以启用“允许脚本访问 OAuth 令牌”，这将启用与 Azure RM 的后续定制连接。
坏消息是 Microsoft.Azure.Services.AppAuthentication 库（如果您使用 MSI，我认为您正在使用）没有允许访问令牌的连接字符串，它只有客户端密码。
因此有几个选项，您可以找到部署代理服务主体并添加另一个预先共享的客户端密码并在您的连接字符串中使用它，请注意将其作为安全变量传递，以免它无法检索。
弱点是你现在有一个位置，你的部署代理服务主体现在有一个有人知道的密码，以前它只是 Azure DevOps 和 Active Directory 之间的巫术。
或者，我建议[创建一个服务主体] 专用于集成测试 keyvault 2，并将客户端密码用作管道中的密码变量。与部署代理服务主体遭到入侵相比，使用专用服务主体可以减少攻击媒介。
您可以通过存储在环境设置中的连接字符串设置 AppAuthentication 库，这意味着无需更改您的代码：https ://docs.microsoft.com/en-us/azure/key-vault/service-to-service-authentication#连接字符串支持