我有一个ASP.Net Core 2.1项目，其中的测试项目包含一些集成测试，这些测试要求/需要Azure托管服务身份访问才能成功运行（从KeyVault中获取机密）。我正在使用Azure DevOps VS2017托管生成代理来生成项目以部署到Azure App Service。我遇到的问题是，当测试在生成管道之后运行时，它们将失败，因为托管的生成代理上没有MSI访问权限。我该如何设置托管构建代理所需的适当MSI访问权限？是否可以通过Powershell任务或其他等效方法来做到这一点？
谢谢！
答案 0 :(得分：0)
要退后一步，您可能已经知道这一点，但是只是在解释我的思考过程：
托管服务身份的想法仅仅是服务主体（即服务帐户），您不知道密码，而且比用户为您创建并由Microsoft管理用户更重要。
从这种意义上讲，只要您通过托管代理可以假定其身份的密钥库访问策略授予服务主体访问权限，就可以对您进行排序。
好消息和坏消息。好消息是，至少在使用Azure PowerShell任务时，托管代理会附带服务主体，就像MSI一样，您不知道密码（除非您添加了机密），但它们会为您预先登录。
在“阶段”设置中，您可以启用“允许对OAuth令牌的脚本访问”，以启用到Azure RM的后续定制连接。
坏消息是，如果您使用的是MSI，我假设您正在使用Microsoft.Azure.Services.AppAuthentication库，它没有允许访问令牌的连接字符串，它仅具有客户端密码。 / p>
因此，有两种选择，您可以找到deployment agent service principal并添加另一个预共享的客户端机密，并在连接字符串中使用该机密，请小心将其作为安全变量传递，以使其不可检索。
缺点是您现在可以在某个位置上，您的部署代理服务主体现在有了一个可以知道的密码，该密码以前只是Azure DevOps和Active Directory之间的伏都教。
或者，我建议您[创建一个服务主体]专门用于集成测试密钥库2，并将客户端密钥用作管道中的密钥变量。与您的部署代理服务主体受到威胁相比，使用专用服务主体可以减少攻击向量。
您可以通过存储在环境设置中的连接字符串来设置AppAuthentication库，这意味着无需更改代码：https://docs.microsoft.com/en-us/azure/key-vault/service-to-service-authentication#connection-string-support