一，引言
又到了新的一周了，也到了我新的分享的時間了，還記得上一周立得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內置角色：https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
作者：Allen
版權：轉載請在文章明顯位置註明作者及出處。如發現錯誤，歡迎批評指正。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※想知道最厲害的網頁設計公司"嚨底家"!
※別再煩惱如何寫文案,掌握八大原則!
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※回頭車貨運收費標準
※台中搬家公司費用怎麼算?