授與服務主體存取 Azure 的權限

已完成

服務主體本身無法在您的 Azure 環境中進行任何動作。 這就像使用者無法使用您的 Azure 資源,除非他們取得授權。 在此單元中,您將瞭解如何授權服務主體來部署和設定 Azure 資源,同時避免授與不必要的權限。

注意

本單元中的命令僅用於示範概念。 請先不要執行命令。 您很快就會在此練習所學到的內容。

服務主體授權

到目前為止,您已將焦點放在服務主體是什麼,以及如何使用其來證明管線到 Microsoft Entra ID 的身分識別。 這攸關於驗證

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

注意

您在這裡的一切操作都是使用 Azure RBAC 系統來授與存取權,以建立和管理 Azure 資源,例如儲存體帳戶、App Service 方案和虛擬網路。 Microsoft Entra ID 也有自己的角色系統,有時也稱為目錄角色。 您可以使用這些角色來授與服務主體管理 Microsoft Entra ID 的權限。 本課程模組不會深入討論此主題,但請注意,在某些文件中,這兩種情況都可使用「角色」一詞。

為您的管線選取正確的角色指派

角色指派有三個主要部分:角色指派給誰 (受託人)、他們可以做什麼 (角色),以及角色指派套用至 (範圍) 什麼樣的資源。

受託人

當您使用服務主體時,您可以為該服務主體指派角色。 您可以使用服務主體的應用程式識別碼來識別該受託人的正確服務主體。

角色

可能需要花點時間來找出要指派的角色。 在 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 00001111-aaaa-2222-bbbb-3333cccc4444 \
  --role Contributor \
  --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline 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 00001111-aaaa-2222-bbbb-3333cccc4444 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

讓我們看看每個引數:

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

提示

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

注意

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

在一個作業中建立服務主體和角色指派

您也可以在建立服務主體的同時,建立角色指派。 此程式碼類似於您用來在先前單元中建立服務主體的命令,但是有一些額外的引數:

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"
$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

使用 Bicep 授與存取權

角色指派是 Azure 資源。 這表示您可以使用 Bicep 來建立角色指派。 如果您使用 Bicep 來初始化資源群組,然後使用服務主體將資源部署至資源群組,則您可以這麼做。 以下是上述角色指派的範例 Bicep 定義:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c
  • principalId 是服務主體的物件識別碼。 請確定您未使用應用程式識別碼或應用程式註冊的物件識別碼。
  • description 是人們看得懂的角色指派描述。