Azure AD（四）知識補充-服務主體
一，引言
又到了新的一周了，也到了我新的分享的時間了，還記得上一周立得Flag，其中 「保證每周輸出一篇文章」 ，讓我特別「在意」（這裡用詞不太恰當）。主要是我的一個大學舍友，他突然問了我一個關於寫博的事情，自己也在上周開通了帳號，也想著堅持寫部落格。在我看來，這確實是一件好事，寫博不僅僅是分享的過程；也是自己提煉寫博的一個過程，以及文章組織的能力，對自己還是很有好處的。這不僅僅要寫內容要精鍊，同時也要讓別人能看的懂。加油，默默的在這裡給他打氣。(ง •_•)ง
好了，開始今天的分析👇👇👇👇👇
————————————我是分割線————————————
上一周有介紹到Azure AD資源託管標識的內容，其實就包括如何去操作開啟系統分配的託管標識，以及通過開啟託管標識，VM如何去訪問Azure 中的一些資源，如 「Key Vault」 等。今天去分析一波關於「Service Principal」（服務主體）。
二，正文
1，服務主體對象
若要訪問受 Azure AD 租戶保護的資源，需要訪問的實體必須由安全主體來表示。 這同時適用於用戶（用戶主體）和應用程式（服務主體）。安全主體定義 Azure AD 租戶中用戶/應用程式的訪問策略和許可權。 這樣便可實現核心功能，如在登錄時對用戶/應用程式進行身份驗證，在訪問資源時進行授權。當應用程式被授予了對租戶中資源的訪問許可權時（根據註冊或許可），將創建一個服務主體對象。 Microsoft Graph ServicePrincipal 實體定義服務主體對象屬性的架構。
2，應用程式和服務主體的關係
可以將應用程式對象視為應用程式的全局表示形式（供所有租戶使用），將服務主體視為本地表示形式（在特定租戶中使用）。
應用程式對象用作模板，常見屬性和默認屬性從其中派生，以便在創建相應服務主體對象時使用。 因此，應用程式對象與軟體應用程式存在 1 對 1 關係，而與其對應的服務主體對象存在 1 對多關係。
必須在將使用應用程式的每個租戶中創建服務主體，讓它能夠建立用於登錄和/或訪問受租戶保護的資源的標識。 單租戶應用程式只有一個服務主體（在其宿主租戶中），在應用程式註冊期間創建並被允許使用。 多租戶 Web 應用程式/API 還會在租戶中的某個用戶已同意使用它的每個租戶中創建服務主體。
下圖演示了應用程式的應用程式對象和對應的服務主體對象之間的關係，其上下文是在名為 HR 應用的示例多租戶應用程式中。 此示例方案中有三個 Azure AD 租戶：
- Adatum -開發HR 應用的公司使用的租戶
- Contoso -contoso 組織使用的租戶，即HR 應用的使用者
- Fabrikam -fabrikam 組織使用的租戶，它也使用HR 應用
在此示例方案中：
| 步驟 | 說明 |
|---|---|
| 1 | 是在應用程式的宿主租戶中創建應用程式對象和服務主體對象的過程。 |
| 2 | 當 Contoso 和 Fabrikam 的管理員完成同意並嚮應用程式授予訪問許可權時，會在其公司的 Azure AD 租戶中創建服務主體對象，並向其分配管理員所授予的許可權。 另請注意，HR 應用可能配置/設計為允許由用戶同意以供個人使用。 |
| 3 | HR 應用程式的使用者租戶（例如 Contoso 和 Fabrikam）各有自己的服務主體對象。 每個對象代表其在運行時使用的應用程式實例，該實例受相關管理員同意的許可權控制。 |
3，使用Azure CLI創建Azure服務主體（示例）
使用 az ad sp create-for-rbac 命令創建服務主體。創建服務主體時，請選擇其使用的登錄身份驗證的類型。
注意
如果您的帳戶無權創建服務主體，將返回一條錯誤消息，其中包含「許可權不足，無法完成操作」。請與您的Azure Active Directory管理員聯繫以創建服務主體。
3.1，在 「azure portal」 中驗證當前的Azure訂閱
az account show
3.2，顯示訂閱名稱ID值的列表
az account list --query "[].{name:name, subscriptionId:id}"
3.3，使用 az ad sp create-for-rbac 命令，將其替換<subscription_id>為要使用的訂閱帳戶的ID
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/<subscription_id>"
注意：我們將創建一個具有 「Contributor」 （貢獻者角色：默認角色）的服務主體。該 「Contributor」 角色具有完全的許可權讀取和寫入到Azure的賬戶，
成功完成後，該命令將顯示幾個值，包括自動生成的密碼
同時，我們可以在 「azure portal」 中可以找到對應的設置 選擇=》Azure Active Directory
點擊 「App registrations」
同時，我們可以在當前訂閱下的 「IAM」中找到對應的角色訪問許可權資訊。當然了，上面我創建服務主體的時候給的 scope 是整個訂閱，也就是我們可以通過這個服務主體去訪問azure的任何資源。
例如 “azure devops Pipeline” 在CD的過程，需要配置 “Service Principal”
例如使用Terraform 構建基礎架構資源的時候，需要配置 Service Principal
三，總結
使用Azure服務的自動化工具應始終具有受限許可權。Azure提供服務主體，而不是讓應用程式以完全特權用戶身份登錄。Azure服務主體是為與應用程式，託管服務和自動化工具一起使用而創建的身份，以訪問Azure資源。這種訪問受到分配給服務主體的角色的限制，使您可以控制可以訪問哪些資源以及可以訪問哪個級別。出於安全原因，始終建議將服務主體與自動化工具一起使用，而不是允許他們使用用戶身份登錄。
服務主體的默認角色是Contributor。該角色具有讀取和寫入Azure帳戶的完整許可權
參考資料：RBAC內置角色：//docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
作者：Allen
版權：轉載請在文章明顯位置註明作者及出處。如發現錯誤，歡迎批評指正。
