Jul*_*Net 5 azure azure-active-directory azure-devops azure-managed-identity
我有一个ASP.Net Core 2.1项目,其中的测试项目包含一些集成测试,这些测试要求/需要Azure托管服务身份访问才能成功运行(从KeyVault中获取机密)。我正在使用Azure DevOps VS2017托管生成代理来生成项目以部署到Azure App Service。我遇到的问题是,当测试在生成管道之后运行时,它们将失败,因为托管的生成代理上不支持MSI访问。我该如何设置托管构建代理所需的适当MSI访问权限?是否可以通过Powershell任务或等效方法来执行此操作?
谢谢!
退一步来说,你可能已经知道这一点,但只是解释一下我的思考过程:
托管服务身份只是您不知道密码的服务主体(即服务帐户),而且用户是为您创建并由 Microsoft 管理的。
因此,从这个意义上说,只要您通过托管代理可以假定其身份的 keyvault 访问策略授予服务主体访问权限,您就可以进行排序。
有好消息和坏消息。好消息是,托管代理至少在使用 Azure PowerShell 任务时带有服务主体,就像 MSI 一样,您不知道密码(除非您添加密码),但它们会为您预先登录。
在“阶段”设置中,您可以启用“允许脚本访问 OAuth 令牌”,从而启用与 Azure RM 的后续定制连接。
坏消息是,如果您使用 MSI,我假设您正在使用 Microsoft.Azure.Services.AppAuthentication 库,它没有允许访问令牌的连接字符串,它只有客户端密钥。
因此,有几个选项,您可以找到部署代理服务主体并添加另一个预共享客户端密钥并在连接字符串中使用它,请小心地将其作为安全变量传递,以便它不可检索。
弱点在于,您现在的部署代理服务主体现在拥有一个有人知道的密码,而该密码以前只是 Azure DevOps 和 Active Directory 之间的巫术。
或者,我建议是[创建一个服务主体]专用于集成测试 keyvault 2,并使用客户端密钥作为管道中的秘密变量。与部署代理服务主体受到威胁相比,使用专用服务主体可以减少攻击媒介。
您可以通过环境设置中存储的连接字符串来设置 AppAuthentication 库,这意味着无需更改代码: https: //learn.microsoft.com/en-us/azure/key-vault/service-to-service-authentication#连接字符串支持
| 归档时间: |
|
| 查看次数: |
1007 次 |
| 最近记录: |