授與工作負載身分識別對 Azure 的存取權

  • 6 分鐘

根據本身，工作負載身分識別無法在 Azure 環境中執行任何動作，就像使用者無法與 Azure 資源搭配使用的方式一樣，除非他們獲得授權才能這麼做。 在本單元中，您將瞭解如何授權工作負載身分識別來部署和設定 Azure 資源，同時避免授與不必要的許可權。

工作負載身分識別授權

到目前為止，您已將焦點放在工作負載身分識別是什麼，以及如何使用其來證明部署工作流程到 Microsoft Entra ID 的身分識別。 這攸關於驗證。

在 Microsoft Entra ID 驗證工作負載身分識別後，下一個問題就會變成：此工作負載身分識別可以執行哪些動作？ 這是授權的概念。 這是 Azure 角色型存取控制 (RBAC) 系統 (有時稱為身分識別和存取管理 (IAM)) 的責任。 藉由使用 Azure RBAC，您可以將特定資源群組、訂用帳戶或管理群組的存取權授與工作負載身分識別。

注意

您在這裡所做的一切都是使用 Azure RBAC 系統來授與建立和管理 Azure 資源的存取權，例如您的記憶體帳戶、Azure App 服務 方案和虛擬網路。 Microsoft Entra ID 也有自己的角色系統，有時也稱為目錄角色。 您可以使用這些角色來授與工作負載身分識別管理 Microsoft Entra ID 的權限。 本課程模組不會深入討論此主題，但請注意，一些檔中這兩種情況都會使用角色一詞。

為您的工作流程選取正確的角色指派

角色指派有三個主要部分：角色指派給誰（被指派者）、他們可以執行的動作（角色），以及角色指派所套用的資源或資源（範圍）。

受託人

當您使用工作負載身分識別時，會為其指派角色。 若要指派角色，您必須先建立 服務主體，這可讓您在 Azure 中授與應用程式角色。 建立服務主體之後，您可以繼續使用應用程式註冊的應用程式識別碼。

若要建立服務主體，請使用 az ad sp create 命令，並指定應用程式註冊的應用程式識別碼：

az ad sp create --id A123b4567c-1234-1a2b-2b1a-1234abc12345

若要建立服務主體，請使用 New-AzADServicePrincipal Cmdlet，並指定應用程式註冊的應用程式識別碼：

New-AzADServicePrincipal -AppId A123b4567c-1234-1a2b-2b1a-1234abc12345

角色

可能需要花點時間來找出要指派的角色。 在 Azure 中，有幾個常見的角色：

  • 讀者：允許被指派者讀取資源的相關信息，但無法修改或刪除資源。
  • 參與者：允許被指派者建立資源，以及讀取和修改現有的資源。 不過，參與者無法將資源的存取權授與其他主體。
  • 擁有者：可讓您完全掌控資源，包括授與其他主體存取權。

警告

請只授與工作負載身分識別完成其工作所需的最小授權。 大部分的情況下，「擁有者」角色對部署工作流程而言太寬鬆。

另外還有許多特定的角色，會提供功能子集的存取權。 您甚至可以建立自己的自訂角色定義，以指定您想要指派的確切權限清單。

注意

自訂角色定義可以是將權限授與 Azure 資源的有效方式，但很難使用。 確切判斷您需要新增至自訂角色定義的權限不一定容易。 您可能會不小心讓角色定義過於嚴格或太過寬鬆。

如果您不確定該怎麼做，最好使用其中一個內建角色定義。 自訂角色定義已超出本課程模組的範圍。

範圍

您必須判斷指派角色的範圍。 這項決定會影響工作負載身分識別可以修改的資源數目。 常見的範圍包括：

  • 單一資源：您可以將存取權授與特定資源。 一般而言，部署工作流程不會使用此範圍，因為工作流程會建立尚未存在的資源，或重新配置多個資源。
  • [資源群組]：您可以將存取權授與資源群組內的所有資源。 「參與者」和「擁有者」也可以在群組內建立資源。 對於許多部署工作流程來說是絕佳選項。
  • [訂用帳戶]：您可以將存取權授與訂用帳戶內的所有資源。 如果您在單一訂用帳戶中有多個應用程式、工作負載或環境，則可以授與訂用帳戶範圍的權限。 不過，這通常對部署工作流程而言太寬鬆。 除非您的部署工作流程需要建立資源群組，否則您應該改為考慮將角色指派範圍界定為資源群組。

請記住，角色指派是繼承的。 如果您在訂用帳戶上指派角色，則被指派者可以存取該訂用帳戶內的每個資源群組和資源。

選取正確的角色指派

既然您已了解角色指派的元件，現在可以為您的案例決定適當的值。 下面有些一般方針需要考量：

  • 盡可能使用最不寬鬆的角色。 如果您的工作流程只是要部署基本 Bicep 檔案，而不會管理角色指派，請不要使用「擁有者」角色。

  • 盡可能使用最小的範圍。 大部分的工作流程只需要將資源部署至資源群組，因此不應取得訂用帳戶範圍的角色指派。

  • 對於許多工作流程，角色指派的良好預設選項是資源群組範圍的「參與者」角色。

  • 請考慮工作流程所做的一切，以及未來可能所做的一切。 例如，您可以考慮為網站的部署工作流程建立自訂角色定義，並且只授與 App Service 和 Application Insights 權限。 下個月，您可能需要將 Azure Cosmos DB 帳戶新增至 Bicep 檔案，但自訂角色會封鎖 Azure Cosmos DB 資源的建立。

    相反地，通常最好使用內建角色或內建角色的組合，以避免重複變更您的角色定義。 請考慮使用 Azure 原則，以針對允許的服務、SKU 和位置強制執行您的治理需求。

  • 測試工作流程，以驗證角色指派是否正常運作。

角色指派的混合和比對

您可以建立多個在不同範圍提供不同權限的角色指派。 例如，您可以指派具有整個訂閱範圍的「讀者」角色給工作負載身分識別。 您可以個別指派相同工作負載身分識別給特定資源群組的參與者角色。 當工作負載身分識別嘗試使用資源群組時，會套用更寬鬆的指派。

使用多個環境

您可能會在應用程式中使用多個環境，例如開發、測試和實際執行環境。 每個環境的資源都應該部署至不同的資源群組或訂用帳戶。

您應該要針對每個環境建立個別的工作負載身分識別。 請授與每個工作負載身分識別其部署所需的最小權限集合。 請特別小心，以避免將生產環境部署的權限與非生產環境部署的權限混合使用。

建立工作負載身分識別的角色指派

若要建立工作負載身分識別的角色指派，請使用 az role assignment create 命令。 您必須指定「受託人」、「角色」和「範圍」：

az role assignment create \
  --assignee A123b4567c-1234-1a2b-2b1a-1234abc12345 \
  --role Contributor \
  --scope "/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite" \
  --description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

讓我們看看每個引數：

  • --assignee 指定工作負載身分識別。 您可以透過數種方式來指定此引數，但最好使用應用程式識別碼，因為這麼做可避免模棱兩可。
  • --role 指定角色。 如果您使用內建角色，則可以依名稱指定。 如果您使用自訂角色定義，請指定完整的角色定義識別碼。
  • --scope 指定範圍。 這通常是單一資源、資源群組或訂用帳戶的資源識別碼。
  • --description 是人們看得懂的角色指派描述。

若要建立工作負載身分識別的角色指派，請使用 New-AzRoleAssignment Cmdlet。 請指定受託人、角色和範圍：

New-AzRoleAssignment `
  -ApplicationId A123b4567c-1234-1a2b-2b1a-1234abc12345 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite' `
  -Description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

讓我們看看每個引數：

  • -ApplicationId 指定工作負載身分識別的應用程式註冊識別碼。
  • -RoleDefinitionName 指定內建角色的名稱。 如果您使用自訂角色定義，請改為使用 -RoleDefinitionId 引數來指定完整的角色定義識別碼。
  • -Scope 指定範圍。 這通常是單一資源、資源群組或訂用帳戶的資源識別碼。
  • -Description 是人們看得懂的角色指派描述。

提示

您可以藉由指定描述，為角色指派提供理由，是很好的做法。 描述可協助任何人在稍後檢查角色指派，以瞭解其用途，以及瞭解您如何決定您的受託人、角色和範圍。

注意

角色指派可能需要幾分鐘的時間才會變成作用狀態。

使用 Bicep 授與存取權

角色指派是 Azure 資源。 這表示您可以使用 Bicep 來建立角色指派。 如果您使用 Bicep 初始化資源群組，然後使用工作負載身分識別將資源部署至資源群組，您可能會這麼做。 以下是上述角色指派的範例 Bicep 定義：

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment workflow for the company\'s website needs to be able to create resources within the resource group.'
  }
}

讓我們看看每個引數：

  • name 是角色指派的全域唯一識別碼 (GUID)。 最好使用 Bicep 的 guid() 函式來建立 GUID。 若要確保您為每個角色指派建立唯一的名稱，請使用主體識別碼、角色定義識別碼和範圍作為函式的種子引數。

  • principalType 應該設定為 ServicePrincipal。

  • roleDefinitionId 是您要指派角色定義的完整資源識別碼。 您大多會使用內建角色，因此您可以在 Azure 內建角色文件中找到角色定義識別碼。

    例如，參與者角色具有角色定義識別碼 b24988ac-6180-42a0-ab88-20f7382dd24c。 當您在 Bicep 檔案中指定時，您會使用完整資源識別碼，例如 /subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c。

  • principalId 是服務主體的物件識別碼。 請確定您未使用應用程式識別碼或應用程式註冊的物件識別碼。

  • description 是人們看得懂的角色指派描述。