一，引言

　　又到了新的一周了，也到了我新的分享的時間了，還記得上一周立得Flag，其中 “保證每周輸出一篇文章” ，讓我特別“在意”（這里用詞不太恰當）。主要是我的一個大學舍友，他突然問了我一個關于寫博的事情，自己也在上周開通了賬號，也想著堅持寫博客。在我看來，這確實是一件好事，寫博不僅僅是分享的過程；也是自己提煉寫博的一個過程，以及文章組織的能力，對自己還是很有好處的。這不僅僅要寫內(nèi)容要精煉，同時也要讓別人能看的懂。加油，默默的在這里給他打氣。(? ?_?)?

好了，開始今天的分析????????????????????

------------------------------------我是分割線------------------------------------

　　上一周有介紹到Azure AD資源托管標識的內(nèi)容，其實就包括如何去操作開啟系統(tǒng)分配的托管標識，以及通過開啟托管標識，VM如何去訪問Azure 中的一些資源，如 “Key Vault” 等。今天去分析一波關于“Service Principal”（服務主體）。

二，正文

1，服務主體對象

　　若要訪問受 Azure AD 租戶保護的資源，需要訪問的實體必須由安全主體來表示。?這同時適用于用戶（用戶主體）和應用程序（服務主體）。安全主體定義 Azure AD 租戶中用戶/應用程序的訪問策略和權限。?這樣便可實現(xiàn)核心功能，如在登錄時對用戶/應用程序進行身份驗證，在訪問資源時進行授權。當應用程序被授予了對租戶中資源的訪問權限時（根據(jù)注冊或許可），將創(chuàng)建一個服務主體對象。?Microsoft Graph ServicePrincipal 實體定義服務主體對象屬性的架構。

2，應用程序和服務主體的關系

可以將應用程序對象視為應用程序的全局表示形式（供所有租戶使用），將服務主體視為本地表示形式（在特定租戶中使用）。

應用程序對象用作模板，常見屬性和默認屬性從其中派生，以便在創(chuàng)建相應服務主體對象時使用。?因此，應用程序對象與軟件應用程序存在 1 對 1 關系，而與其對應的服務主體對象存在 1 對多關系。

必須在將使用應用程序的每個租戶中創(chuàng)建服務主體，讓它能夠建立用于登錄和/或訪問受租戶保護的資源的標識。?單租戶應用程序只有一個服務主體（在其宿主租戶中），在應用程序注冊期間創(chuàng)建并被允許使用。?多租戶 Web 應用程序/API 還會在租戶中的某個用戶已同意使用它的每個租戶中創(chuàng)建服務主體。

下圖演示了應用程序的應用程序對象和對應的服務主體對象之間的關系，其上下文是在名為 HR 應用的示例多租戶應用程序中。?此示例方案中有三個 Azure AD 租戶：

• Adatum?-開發(fā)HR 應用的公司使用的租戶

• Contoso?-contoso 組織使用的租戶，即HR 應用的使用者

• Fabrikam?-fabrikam 組織使用的租戶，它也使用HR 應用

在此示例方案中：

表 1步驟說明

1	是在應用程序的宿主租戶中創(chuàng)建應用程序對象和服務主體對象的過程。
2	當 Contoso 和 Fabrikam 的管理員完成同意并向應用程序授予訪問權限時，會在其公司的 Azure AD 租戶中創(chuàng)建服務主體對象，并向其分配管理員所授予的權限。?另請注意，HR 應用可能配置/設計為允許由用戶同意以供個人使用。
3	HR 應用程序的使用者租戶（例如 Contoso 和 Fabrikam）各有自己的服務主體對象。?每個對象代表其在運行時使用的應用程序實例，該實例受相關管理員同意的權限控制。

3，使用Azure CLI創(chuàng)建Azure服務主體（示例）

使用?az ad sp create-for-rbac?命令創(chuàng)建服務主體。創(chuàng)建服務主體時，請選擇其使用的登錄身份驗證的類型。

?注意

如果您的帳戶無權創(chuàng)建服務主體，將返回一條錯誤消息，其中包含“權限不足，無法完成操作”。請與您的Azure Active Directory管理員聯(lián)系以創(chuàng)建服務主體。

3.1，在 “azure portal” 中驗證當前的Azure訂閱

1	az account show

3.2，顯示訂閱名稱ID值的列表

1	az account list --query?"[].{name:name, subscriptionId:id}"

?

3.3，使用?az ad sp create-for-rbac?命令，將其替換<subscription_id>為要使用的訂閱帳戶的ID

1	az ad sp create-for-rbac --role="Contributor"?--scopes="/subscriptions/<subscription_id>"

注意：我們將創(chuàng)建一個具有 “Contributor” （貢獻者角色：默認角色）的服務主體。該 “Contributor” 角色具有完全的權限讀取和寫入到Azure的賬戶，

成功完成后，該命令將顯示幾個值，包括自動生成的密碼　　

?

同時，我們可以在 “azure portal” 中可以找到對應的設置 選擇=》Azure Active Directory

?

點擊 “App registrations”

?

?同時，我們可以在當前訂閱下的 “IAM”中找到對應的角色訪問權限信息。當然了，上面我創(chuàng)建服務主體的時候給的 scope 是整個訂閱，也就是我們可以通過這個服務主體去訪問azure的任何資源。

例如 "azure devops Pipeline" 在CD的過程，需要配置 "Service Principal"

?

?例如使用Terraform 構建基礎架構資源的時候，需要配置 Service Principal

三，總結

　　使用Azure服務的自動化工具應始終具有受限權限。Azure提供服務主體，而不是讓應用程序以完全特權用戶身份登錄。Azure服務主體是為與應用程序，托管服務和自動化工具一起使用而創(chuàng)建的身份，以訪問Azure資源。這種訪問受到分配給服務主體的角色的限制，使您可以控制可以訪問哪些資源以及可以訪問哪個級別。出于安全原因，始終建議將服務主體與自動化工具一起使用，而不是允許他們使用用戶身份登錄。

服務主體的默認角色是Contributor。該角色具有讀取和寫入Azure帳戶的完整權限

參考資料：RBAC內(nèi)置角色：https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles

作者：Allen

版權：轉載請在文章明顯位置注明作者及出處。如發(fā)現(xiàn)錯誤，歡迎批評指正。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的[壹刊]Azure AD（四）知识补充-服务主体的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。