我有一个 ASP.Net Core 2.1 项目，其中包含一些集成测试，需要 Azure 托管服务标识访问才能成功运行(从 KeyVault 获取 secret )。我正在使用 Azure DevOps VS2017 托管构建代理来构建项目以部署到 Azure 应用服务。我遇到的问题是，当测试在构建管道之后运行时，它们会失败，因为 MSI 访问在托管构建代理上不可用。如何设置托管构建代理所需的适当 MSI 访问权限？是否可以通过 Powershell 任务或类似的任务来做到这一点？
谢谢!
最佳答案
退一步来说，您可能已经知道这一点，但只是为了解释我的思考过程:
将托管服务身份视为简单的服务主体(即服务帐户)，您不知道密码，而且用户是为您创建并由 Microsoft 管理的。
因此，从这个意义上说，只要您通过 keyvault 访问策略授予服务主体访问权限(您的托管代理可以假定其身份)，您就可以进行排序。
有好消息和坏消息。好消息是，托管代理至少在使用 Azure PowerShell 任务时带有服务主体，就像 MSI 一样，您不知道密码(除非您添加密码)，但它们会为您预先登录。
在“阶段”设置中，您可以启用“允许脚本访问 OAuth token ”，从而启用与 Azure RM 的后续定制连接。
坏消息是，如果您使用 MSI，我假设您正在使用 Microsoft.Azure.Services.AppAuthentication 库，它没有允许访问 token 的连接字符串，它只有客户端 key 。
有几个选项，您可以找到 deployment agent service principal并添加另一个预共享的客户端 key 并在连接字符串中使用它，请小心地将其作为安全变量传递，以便它不可检索。
弱点在于，您现在的部署代理服务主体现在拥有一个有人知道的密码，而该密码以前只是 Azure DevOps 和 Active Directory 之间的巫术。
或者，我建议是[创建一个服务主体]专用于集成测试 keyvault 2 ，并使用客户端 key 作为管道中的 key 变量。与部署代理服务主体受到威胁相比，使用专用服务主体可以减少攻击媒介。
您可以通过环境设置中存储的连接字符串来设置 AppAuthentication 库，这意味着无需更改代码:https://learn.microsoft.com/en-us/azure/key-vault/service-to-service-authentication#connection-string-support
关于Azure DevOps 托管构建代理 MSI，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53470481/