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