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

步驟	說明
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 

版權：轉載請在文章明顯位置註明做者及出處。如發現錯誤，歡迎批評指正。