在 Azure 上很常利用 Key Vault 來儲存一些所需要使用的密碼或金鑰，但指派使用者的權限要稍微注意一下
這幾年在使用 Azure 的時候，有些時候會為了安全性，也有些時候會想要統一控管，因此很常就會利用 Key Vault 來存放像是秘密或是憑證，如果相關 Web App 或者是 Azure Function 要去使用的時候，只要設定的時候使用下列方式進行設定，就可以不用在程式中去儲存這些連線資訊，要定時更換相關密碼也就方便得多了。
@Microsoft.KeyVault(SecretUri={Key Vault 屬性位址})原本這些設定都是自己在弄，但是最近因為剛好事情變多了，加上 ISO 27001 稽核的時候會要求將這些程序給標準化並且可以有人可以代理，這個時候才發現原來有很多細節自己太久之前設定了，或者是後來設定規格有改變，導致有些地方沒有做得很順，因此在整理公司內的程序的時候，順便整理一下自己的 Blog 當成一個自己的筆記囉。
首先在 Key Vault ( 金鑰保存庫 ) 上，在存取設定中會有兩種的權限模型，會來決定誰可以使用 Key Vault 的權限要設定在哪裡，這裡我通常會習慣使用「保存庫存取原則」
這樣設定的影響主要是後續權限你要設定在IAM 還是存取原則上， 基本上都是可以達到相同的，就看您自己的偏好。我自己是因為習慣在 IAM 設定相關可以控制的人員，應用程式可以讀取就放在存取原則上，所以上述的設定我就會採用「保存庫存取原則」
因為我們在指派哪一些相關 Azure 服務要來存取金鑰，這個時候要特定在那些服務上，要在「設定」→「身分識別」去將識別給開啟，這樣就會在 Microsoft Entra 內有一筆開服務的紀錄了，後續才可以在 Key Vault 的存取原則上指派這些服務有權限可以處理。
以我自己的環境為例，我們的 Key Vault 上面的存取原則中就會指定需要讀取 Key Vault 的應用程式，對於秘密 ( Secrects ) 有取得 ( Get ) 的權限
原本覺得這樣設定就很 OK，讓相關維運的人可以對 Key Vault 有管理的權限就可以設定，但是沒有想到當我權限指派給相關人員之後，他們進入到「存取原則」的「建立」時候，卻發生沒有辦法指派主體的狀況 ?!
正常來說應該可以進入存取原則就應該是有相關權限，怎麼會在這一塊卡關呢? 後來反覆查看幾個狀況和驗證使用者的權限，這主要是我們內部再使用 Microsoft Entra ( 之前稱為 AAD ) 的一個後遺症，因為早期在使用 Azure 的時候，相關人員對於 Azure 管理不熟，使得公司有三個不同的 AAD，導致後來我們只能暫時被迫要將將公司人員加入 Microsoft Entra 的時候，要使用邀請外部使用者的方式，因此這個時候相關人員的帳號是無法讀取 Microsoft Entra 的資訊，才會有這樣的狀況。
既然知道原因那設定就單純多了，只要將該「來賓」的帳號，在 Microsoft Entra 下面檢查一下「指派的角色」，正常來說應該會是空的。這個時候我們選擇「新增指派」
然後指派「目錄讀取者」的角色
這樣就可以讓相關管理員在 Key Vault 去指定哪些服務可以來讀取了。