Azure 應用的托管身份與服務主體

Microsoft Entra ID -- 前稱 Azure Active Directory -- 提供強大的身份驗證和授權功能。托管身份和服務主體通過限制憑據暴露的風險來幫助確保對 Azure 資源的訪問安全。

托管身份為Azure原生應用程序自動管理身份，而服務主體則非常適合需要訪問Azure資源的外部應用程序。

托管身份簡化了授予Azure服務訪問其他資源的過程，通過自動管理標識來實現。相比之下，服務主體提供了更詳細的控制級別，對于自動化任務和將外部應用程序集成到Azure資源中至關重要。區分這兩種方法提高了安全性，并簡化了資源管理和運營效率。

在比較 Azure 中的托管身份和服務主體時，出現以下關鍵差異：

身份分配和刪除。
自動與手動憑據管理。
憑據暴露和風險。
在 Azure 原生應用程序與外部應用程序中的使用。

理解這些身份驗證方法對于維護安全和高效的云基礎設施至關重要，無論是配置需要訪問存儲賬戶的虛擬機，還是使用 Azure DevOps 自動化部署。

托管身份（managed identity）

Microsoft Entra ID 中的受管身份使 Azure 服務能夠在不安全地管理憑據的情況下，向其他 Azure 資源進行身份驗證。它自動提供一個可以獲取 Entra ID 令牌的身份。這個過程消除了硬編碼憑據的需要，從而增強了安全性，并簡化了身份驗證和授權。

受管身份有兩種選項可供選擇：

系統分配的托管身份。
用戶分配的托管身份。

什么是系統分配的托管身份？

系統分配的托管身份是與 Azure 服務實例（例如 VM 或 Web 應用）一起自動創建的。該身份與該資源綁定，使其易于管理但無法共享。例如，由于該身份與服務共享相同的生命周期，刪除服務也會刪除該身份。這種類型的身份在單個資源需要訪問其他 Azure 資源并且需要最少的管理時效果最好。系統分配的托管身份具有以下屬性：

自動創建。
標識生命周期與服務綁定。
需要最少的管理。
最適用于單個資源。

什么是用戶分配的托管身份？

一個具有用戶分配的托管身份的Azure資源獨立操作，用戶可以將該身份分配給一個或多個服務實例。用戶手動創建該身份作為獨立資源，并與任何服務實例分開管理。該身份在明確刪除之前會一直存在。當多個資源共享相同身份時，這個資源特別有用。當用戶需要對身份的生命周期管理有更多靈活性和控制時，它也是有益的。總之，用戶分配的托管身份具有以下特點：

獨立創建。
可以在多個資源之間共享。
更大的管理控制。
需要手動刪除。?

演示?

讓我們快速演示一個場景，使用虛擬機作為 Azure 資源：

從 Azure 門戶中，選擇虛擬機；在設置中找到身份。

將狀態設置為開啟，并保存更改。

然后切換到 Azure key vault / IAM，我們可以定義這個系統分配的托管身份，擁有reader. role（或其他權限）。例如，讀取 Azure 存儲帳戶的訪問密鑰或類似的東西。在指派的對象中選擇managed identity。

同樣，讓我們在下一個示例中移除虛擬機的系統分配托管身份，使用用戶分配的身份（一個 Azure 資源只能鏈接一個，不能同時鏈接兩個……）：從 Azure 虛擬機面板中，導航到身份并將“狀態”切換按鈕關閉。保存設置時會提示您進行確認。

創建一個user managed identity

?然后將該user managed identity指派給這臺web01 vm。

最后在key vault /IAM中為該user identity分配read role。讓它能夠讀取key valut 中的secret。

?保存更改后，結果是現在 Azure 虛擬機以及分配給它們的用戶分配的托管標識的 Web 應用程序都可以從 Azure 密鑰保管庫中讀取我們的secret。

什么是服務主體？

服務主體的定義

服務主體是Microsoft Entra ID中的一種安全身份，使得應用程序、托管服務和自動化工具能夠安全地訪問Azure資源。它的功能類似于用戶身份，但它代表的是一個應用程序或服務，需進行身份驗證并獲得授權以訪問特定資源，而不是人類用戶。

服務主體的分類

服務主體使得應用程序能夠以最小權限登錄并執行任務，確保操作的安全性。Azure中有三種主要類型的服務主體：

應用程序服務主體。當應用程序在Microsoft Entra ID中注冊時，會創建應用程序服務主體。它們代表該應用程序在其部署中的身份，使其能夠在Azure或Microsoft Entra ID中進行身份驗證并訪問資源。
托管身份服務主體。在Azure上啟用托管身份時，會創建托管身份服務主體。這種類型的主體通過為應用程序提供身份，簡化了憑證管理，使其能夠連接到支持Azure身份驗證的資源。
傳統服務主體。這些主體是較舊的方法，通常涉及手動管理憑證，例如密碼或證書。組織通常在現代身份驗證機制不可行的環境中使用這些主體。?

演示：?

PS /home/rockwang415> az ad sp create-for-rbac --name "rockdevblogsp"

復制這些信息；在 Azure DevOps 服務連接的例子中，這些信息將如下使用：?

您只需在相應的參數字段中復制正確的信息：

Subscription Id =  用“/subscriptions/xxxxxx-xxxx-xxxx” 替換
Subscription Name =  從Azure Portal / Subscriptions中查看
Service Principal Id = 從前面的命令的appId獲得
Service Principal Key = 從前面命令的password 獲得
Tenant ID =  azure ad tenant 標識ID

托管身份與服務主體之間的區別

理解托管身份與服務主體之間的區別對于選擇適當的 Azure 資源身份驗證方法至關重要。雖然兩者都能讓應用程序和服務安全地訪問 Azure 資源，但它們具有不同的特征和使用場景。
托管身份簡化了憑據管理，因為 Azure 會自動處理和輪換它們。服務主體則需要手動處理客戶端密鑰或證書，并必須安全存儲和輪換。
在生命周期和范圍方面，用戶可以將托管身份分配為系統分配（用于單個資源）或用戶分配（可在多個資源之間共享）。與此同時，用戶可以獨立創建和刪除服務主體，從而提供更細致的訪問控制。
托管身份適合 Azure 原生資源，而服務主體適合需要與 Azure 交互的外部應用程序或服務。
在安全性方面，托管身份通過避免憑據暴露來增強安全性，由 Azure 管理輪換。相反，服務主體要求嚴格管理憑據以降低風險。

何時使用

每種方式使用托管身份或服務主體的決定取決于幾個因素。當應用程序或服務在 Azure 內運行時，使用托管身份。Azure 可以自動處理憑據管理，并最大程度地降低憑據暴露的風險。托管身份還簡化了身份驗證過程并自動化身份管理，從而減少了管理工作量。
當應用程序或服務在 Azure 之外運行時，服務主體是最佳選擇。它是自動化與 Azure 資源交互的任務或腳本的必要條件，或者需要對權限和訪問級別進行更細致的控制。服務主體還對于與外部服務或第三方應用程序的集成是必要的。它們需要安全的憑據處理和持續的管理，但為外部應用程序提供了更多靈活性。
這兩種方法都支持 Azure RBAC 進行訪問控制，盡管服務主體更適合外部使用。托管身份通過最低限度的憑據暴露簡化了合規性，而服務主體需要更嚴格的政策以滿足 GDPR 或 HIPAA 等法規。

真實場景示例

管理身份的一個使用案例是當 Azure Functions 需要從 Azure Queue Storage 讀取數據并寫入 Azure Cosmos DB 時。用戶為函數啟用一個系統分配的管理身份，并在 Azure RBAC 中分配必要的角色。這簡化了身份驗證，并消除了憑據管理，由 Azure 處理安全性和憑據輪換。
對于服務主體，想象一下一個在第三方 CI/CD 工具中將代碼部署到 Azure 的 DevOps 管道。用戶可以在 Microsoft Entra ID 中創建一個服務主體，分配諸如貢獻者的角色，并在 CI/CD 工具中安全存儲其憑據。這個設置使工具能夠安全地進行身份驗證并自動化 Azure 資源管理。?