了解工作負載身分識別
部署工作流程、應用程式和軟體需要特殊的驗證方式。 在此單元中，您將了解工作負載身分識別對部署工作流程而言很重要的原因、它們如何融入 Azure 的安全性模型，以及其運作方式。
為什麼工作流程需要驗證？
當您部署 Bicep 檔案時，您可以有效地要求 Azure Resource Manager 建立或修改您的 Azure 資源。 在範例案例中，您已建立 Bicep 檔案以部署玩具公司的網站。 Bicep 檔案會宣告包含 Azure App Service 方案、應用程式和 Application Insights 執行個體的資源。
當您部署檔案時，Resource Manager 會檢查資源是否存在。 如果沒有，Resource Manager 會建立資源。 如果有任何資源已經存在，Resource Manager 可確保其設定符合您在 Bicep 檔案中指定的組態。
所有這些作業都需要許可權，因為它們會存取和修改您的 Azure 資源。 部署所需的特定權限則會取決於 Bicep 檔案包含的內容。 若要為您的玩具公司網站部署範例檔案，您需要在正部署的資源群組中具有下列權限：
- 建立部署的能力。 部署為具備
Microsoft.Resources/deployments類型的資源。 - 建立和修改 App Service 方案和應用程式的能力。
- 建立和修改 Application Insights 執行個體的能力。
到目前為止，您可能會使用 Azure CLI 或 Azure PowerShell 來自行部署 Bicep 檔案。 當您使用這些工具時，通常會使用您自己的使用者帳戶，並使用您的瀏覽器進行驗證。 這稱為使用您自己的「身分識別」。 當您提交部署時，Azure 會確認您的身分識別是否具有執行 Bicep 範本所指定之動作的必要權限。
移至 GitHub Actions 部署工作流程之後，您必須使用不同的身分識別類型，因為工作流程會執行部署，而不需要直接介入。
身分識別類型
Microsoft Entra ID 是管理 Azure 身分識別的服務。 一些主要的身分識別類型如下：
- 使用者身分識別：使用者代表通常使用瀏覽器以互動方式登入的人。 使用者通常會在登入時執行額外的安全性檢查，例如多重要素驗證 (MFA)，以及根據其位置或網路的條件式存取。
- 群組：群組代表使用者的集合。 群組不會直接進行驗證，但會提供一種便捷的方式，將權限指派給一組使用者。
- 工作負載身分識別：工作負載是一般無人直接執行的自動化程序或系統。 工作負載可以登入 Microsoft Entra ID，但無人登入並與驗證程序互動。 工作負載身分識別沒有 MFA 或類似的保護，因為它們需要人員進行某些動作來證明其身分。
此課程模組著重於工作負載身分識別。
受控識別
受控識別與 Azure 資源相關聯。 Azure 會自動管理認證。 當資源需要存取某些內容時，Azure 會使用認證自動登入。
受控識別適用於 Azure 裝載的資源，例如虛擬機器和 App Service 應用程式。 像是在 Azure 管理自動化、連線到資料庫，以及從 Azure Key Vault 讀取祕密資料等情況時，Azure 資源就很適合自行驗證。 您也可以針對其他案例搭配使用 Azure Arc 與受控識別。
當您使用部署工作流程時，通常不會使用受控識別。 受控識別需要您擁有及管理執行您部署的 Azure 資源。 當您使用 GitHub Actions 時，通常會仰賴 Microsoft 或 GitHub 提供的共用基礎結構。 不過，當您搭配使用工作負載身分識別與 GitHub Actions 時，您會獲得受控識別的主要優點：您不需要管理任何認證。
提示
在解決方案的其他部分中，如果您可以選擇使用受控識別或使用一般的服務主體，最好使用受控識別。 受控識別更容易使用，而且通常更安全。
為什麼您無法只使用您的使用者帳戶？
您可能想知道為什麼當您的使用者帳戶運作良好時，需要建立這個全新的物件類型，只是為了驗證部署工作流程。
使用者帳戶不是專為自動使用而設計。 使用者帳戶的驗證程序通常會檢查人們是否為嘗試登入的實體。 越來越多的組織會在驗證期間使用額外的安全性檢查。 這些檢查包括 MFA、CAPTCHA 檢查，以及檢查使用者正在使用的裝置和網路，以便他們驗證登入要求的合法性。
工作流程的設計目的是執行您的部署，即便沒有人主動執行您的部署也一樣。 事實上，部署工作流程的優點大多都是自動化，且不需要人為互動。
如果您在工作流程中儲存使用者名稱和密碼，並嘗試使用它們來登入，可能會無法運作。 即使看起來正常運作，但如果 Microsoft Entra ID 或您的組織系統管理員對使用者驗證程序新增更多安全性檢查，就很容易在未來中斷。
警告
將您的使用者名稱和密碼儲存在任何地方也是個壞主意，因為其他人可能會取得存取權，然後使用它們來模仿您。
基於這些理由，與 Azure 互動的內建 GitHub Actions 工作不會要求您提供使用者帳戶的認證。 這些工作會要求您使用工作負載身分識別。
工作負載身分識別如何運作？
工作負載身分識別是 Microsoft Entra ID 的一項功能，這是全域身分識別服務。 許多公司都使用 Microsoft Entra ID，而每間公司都稱為租用戶。
Microsoft Entra ID 具有應用程式的概念，代表系統、軟體的一環、處理序或其他非人的代理程式。 您也可以將部署工作流程視為應用程式。
當您建立應用程式並告訴 Microsoft Entra ID 時，則會建立一個稱為應用程式註冊的物件。 應用程式註冊代表 Microsoft Entra ID 中的應用程式。
應用程式註冊可以有相關聯的同盟認證。 同盟認證不需要您儲存任何祕密。 相反地，他們會啟用 GitHub 等支援的服務，以使用 Microsoft Entra 應用程式。
當您的 GitHub Actions 工作流程需要驗證時，則會透過 GitHub 連絡 Microsoft Entra ID。 GitHub 會告知 Microsoft Entra ID GitHub 組織和存放庫的名稱，並選擇性地提供部分其他資訊。 當您設定符合存放庫詳細資料的同盟認證後，Microsoft Entra 即會驗證您的部署工作流程。 工作流程可以使用您已指派給應用程式的權限。
提示
當您在 Azure 入口網站 中查看應用程式註冊時，您會看到許多其他可能不相關的功能和組態。 這是因為應用程式可以在 Microsoft Entra 識別碼中執行許多超出驗證和工作流程部署範圍的事情。
您也可以在 Microsoft Entra 租用戶中建立服務主體物件。 服務主體就像是應用程式複本，可供您自己的 Microsoft Entra 租用戶使用。 服務主體和應用程式密切相關。 當您授與工作流程存取 Azure 的權限時，您將在本課程模組稍後使用服務主體。
注意
部分工具會將服務主體稱為「企業應用程式」。 您也可能會「在本機目錄中看到稱為受控應用程式」的服務主體，但這些服務主體與受控識別不同。