Azure DevOps 托管生成代理 MSI

Question

我有一個 ASP.Net Core 2.1 項目，其中包含一些集成測試，這些測試需要/需要 Azure 托管服務標識訪問才能成功運行（從 KeyVault 獲取機密）。 我正在使用 Azure DevOps VS2017 托管構建代理來構建項目以部署到 Azure 應用服務。 我遇到的問題是，當測試在構建管道之后運行時，它們會失敗，因為托管構建代理上不提供 MSI 訪問。 如何設置托管構建代理所需的適當 MSI 訪問權限？ 是否可以通過 Powershell 任務或等效的東西來做到這一點？

謝謝！

Answer 1

退后一步，您可能已經知道這一點，但只是為了解釋我的思考過程：

想想托管服務標識只是服務主體（即服務帳戶），您不知道密碼，而且用戶是為您創建並由 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# 連接字符串支持