Azure AD（三）知識補充-Azure資源的託管標識

2020 年 6 月 1 日
筆記

一，引言

　　來個慣例，吹水！😅😅😅😅😅

　　前一周因為考試，還有個人的私事，一下子差點頹廢了。想了想，寫博客這種的東西還是得堅持，再忙，也要檢查。要養成一種習慣，同時這也是自我約束的一種形式。雖然說不能浪費大量時間在刷朋友圈，看自媒體的新聞，看一些營銷號的視頻等等，不喜勿噴啊，這是我個人的一些觀念，也沒有帶認識眼光啊！好了，廢話不多說，在此先立個Flag，

　　1，保證每周輸出一片文章。

　　2，開始檢查每周4次的5公里跑步。

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

————————————我是分割線————————————

　　之前有個章節講到Azure AD的一些基礎概念，以及Azure AD究竟可以用來做什麼？，還講了講如何在我們的項目中集成Azure AD 保護我們的API資源！講了這些，其實遠遠不夠，AD里裏面還有好多概念性的知識，同時也是在其他模塊中有使用到的，就比如什麼叫「託管標識」，託管標識又分為「系統託管標識」和「用戶託管標識」；什麼叫「服務主體」，它又能幹什麼，和Azure又有什麼關係？好的，那麼今天就帶着這些問題，我們來剖析，探個究竟！。

二，正文

1，「什麼是託管標識」

客戶端ID：Azure AD 生成的唯一標識符，在其初始預配期間與應用程序和服務主體綁定。
主體 ID – 託管標識的服務主體對象的對象 ID，用於授予對 Azure 資源的基於角色的訪問權限。
Azure 實例元數據服務 (IMDS) – 一個 REST 終結點（url鏈接），可供通過 Azure 資源管理器創建的所有 IaaS VM 使用。

2，託管標識分為兩種類型：

系統分配託管標識：直接在 Azure 服務實例上啟用。啟用標識後，Azure 將在實例的訂閱信任的 Azure AD 租戶中創建實例的標識。創建標識後，系統會將憑據預配到實例。系統分配標識的生命周期直接綁定到啟用它的 Azure 服務實例。如果實例遭刪除，Azure 會自動清理 Azure AD 中的憑據和標識。
用戶分配託管標識：是作為獨立的 Azure 資源創建的。在創建過程中，Azure 會在由所用訂閱信任的 Azure AD 租戶中創建一個標識。在創建標識後，可以將標識分配到一個或多個 Azure 服務實例。用戶分配標識的生命周期與它所分配到的 Azure 服務實例的生命周期是分開管理的。

下圖演示了託管服務標識如何與 Azure 虛擬機 (VM) 協同工作：

3，系統分配託管標識如何與 Azure VM 協同工作

Azure 資源管理器收到請求，要求在 VM 上啟用系統分配託管標識。(圖1)
Azure 資源管理器在 Azure AD 中創建與 VM 標識相對應的服務主體。服務主體在此訂閱信任的 Azure AD 租戶中創建。
Azure 資源管理器通過使用服務主體客戶端 ID 和證書更新 Azure 實例元數據服務標識終結點來配置 VM 上的標識。
VM 有了標識以後，請根據服務主體信息向 VM 授予對 Azure 資源的訪問權限。若要調用 Azure 資源管理器，請在 Azure AD 中使用基於角色的訪問控制 (RBAC) 向 VM 服務主體分配相應的角色。若要調用 Key Vault，請授予代碼對 Key Vault 中特定機密或密鑰的訪問權限。
在 VM 上運行的代碼可以從只能從 VM 中訪問的 Azure 實例元數據服務終結點請求令牌：//169.254.169.254/metadata/identity/oauth2/token
- resource 參數指定了要向其發送令牌的服務。若要向 Azure 資源管理器進行身份驗證，請使用 resource=//management.azure.com/。
- API 版本參數指定 IMDS 版本，請使用 api-version=2018-02-01 或更高版本。
調用了 Azure AD，以便使用在步驟 3 中配置的客戶端 ID 和證書請求訪問令牌（在步驟 5 中指定）。 Azure AD 返回 JSON Web 令牌 (JWT) 訪問令牌。
代碼在調用支持 Azure AD 身份驗證的服務時發送訪問令牌。

4，用戶分配託管標識如何與 Azure VM 協同工作

Azure 資源管理器收到請求，要求創建用戶分配託管標識。
Azure 資源管理器在 Azure AD 中創建與用戶分配託管標識相對應的服務主體。服務主體在此訂閱信任的 Azure AD 租戶中創建。
Azure 資源管理器收到在 VM 上配置用戶分配的託管標識的請求，並使用用戶分配的託管標識服務主體客戶端 ID 和證書更新 Azure 實例元數據服務標識終結點。
創建用戶分配託管標識以後，請根據服務主體信息向標識授予對 Azure 資源的訪問權限。若要調用 Azure 資源管理器，請在 Azure AD 中使用 RBAC 向用戶分配標識的服務主體分配相應的角色。若要調用 Key Vault，請授予代碼對 Key Vault 中特定機密或密鑰的訪問權限。

備註

也可在步驟 3 之前執行此步驟。
在 VM 上運行的代碼可以從只能從 VM 中訪問的 Azure 實例元數據服務標識終結點請求令牌：//169.254.169.254/metadata/identity/oauth2/token
- resource 參數指定了要向其發送令牌的服務。若要向 Azure 資源管理器進行身份驗證，請使用 resource=//management.azure.com/。
- 客戶端 ID 參數指定為其請求令牌的標識。當單台 VM 上有多個用戶分配的標識時，此值是消除歧義所必需的。
- API 版本參數指定 Azure 實例元數據服務版本。請使用 api-version=2018-02-01 或指定更高的版本。
調用了 Azure AD，以便使用在步驟 3 中配置的客戶端 ID 和證書請求訪問令牌（在步驟 5 中指定）。 Azure AD 返回 JSON Web 令牌 (JWT) 訪問令牌。
代碼在調用支持 Azure AD 身份驗證的服務時發送訪問令牌。

稍後會提示

注意，此時在AD的應用註冊頁面是找不到剛剛註冊的應用的,只有在給Azure 資源分配託管標識訪問Azure資源管理器，我這裡是提前創建了是一個vm資源，也就是使用vm系統分配的託管標識訪問Azure Key Vault。簡而言之，Azure Key Vault作為密鑰保管庫，Key Vault 隨後可讓客戶端應用程序使用機密訪問未受 Azure Active Directory (AD) 保護的資源。託管服務標識由 Azure 自動管理，可用於向支持 Azure AD 身份驗證的服務進行身份驗證，這樣就無需在代碼中插入憑據了。

但是Azure中資源和資源之間是相互隔離的，不能夠相互訪問。

所以，我們需要開啟vm的系統分配的託管標識，然後再key vault 中開啟 vm的訪問策略。如下所示

添加「vm001」對「key vault」的訪問策略

創建「機密」信息

名稱輸入:conn；值輸入 123 ，點擊「創建」，

然後使用ssh 登陸剛剛創建好的vm001上，獲取訪問「key vault」的「access_token」

在終端窗口中，使用 CURL 向 Azure 資源終結點的本地託管標識發出請求，以獲取 Azure Key Vault 的訪問令牌

世紀互聯版

curl '//169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.cn' -H Metadata:true

全球版

curl '//169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net' -H Metadata:true

可以使用此訪問令牌對 Azure Key Vault 進行身份驗證。下一個 CURL 請求顯示如何使用 CURL 和 Key Vault REST API 從 Key Vault 讀取密鑰。將需要 Key Vault 的 URL，該 URL 位於 Key Vault 的「概述」頁的「軟件包」部分。另外，還需要在前面的調用中獲取的訪問令牌

curl //<YOUR-KEY-VAULT-URL>/secrets/<secret-name>?api-version=2016-10-01 -H "Authorization: Bearer <ACCESS TOKEN>"

通過在請求頭添加Bearer認證，獲取key vault 中剛剛創建的機密信息名稱「conn」，值「123」

bingo，成功的拿到密鑰。開啟系統分配的託管標識，其實就是授予例如 Azure VM資源的託管標識對另外一個Azure 資源的訪問權限。

三，結尾

今天的文章大概介紹了 Azure系統的託管標識到底是個什麼東西，可以用來幹什麼，這裡不僅僅可以去 VM 訪問 “key Vault”，還可以訪問「Azure 存儲」，「Azure Cosmos DB」等，都是同樣的道理。

下一偏開始講解一下關於用戶自己分配的託管標識，已經作一下演示，同時演示使用用戶分配的託管身份運行應用程序。

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

作者：Allen

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