觀點 · 資訊分享

AKS 掛 Azure Files 不必再塞儲存體金鑰：每個 Pod 用自己的身分，只拿得到該拿的檔案

Azure Files 的 CSI 驅動程式在 AKS 上正式支援工作負載身分：容器可以用自己的身分掛載 SMB 檔案共用，不用把整個儲存體帳號的金鑰放進叢集，權限也能細到單一應用程式。

一句話看懂：AKS 裡的應用程式現在能用自己的身分掛載 Azure Files，不必把整個儲存體帳號的金鑰放進叢集，權限也能細到單一應用程式。

AKS 掛 Azure Files 改用工作負載身分資訊圖卡：每個應用程式用自己的身分拿檔案，不再共用儲存體金鑰

先用白話講：這在解決什麼問題？

想像公司有一間檔案室，裡面放著各部門的資料。過去要讓某個部門進去拿資料，常見做法是給他一把萬能鑰匙：能開檔案室，也能開所有櫃子。鑰匙要是被複製，整間檔案室就被看光了。

在雲端也是一樣。Kubernetes（AKS）裡的程式要讀寫 Azure Files（微軟的雲端共用資料夾），以前常要用儲存體帳號金鑰，那就是一把萬能鑰匙。後來可以改用掛在主機（節點）上的身分，但同一台主機上的所有程式，權限還是一樣大。

這次的更新，等於讓每個應用程式都有自己的員工證，只刷得開它該進的那個櫃子。

微軟在 8 月 28 日的 Azure Updates 宣布正式推出（GA）：

官方特別提到，這對必須遵守嚴格法規的產業很有幫助：可以清楚交代「哪個應用程式能碰哪份資料」。

依 Microsoft Learn 文件，使用條件與步驟是：

parameters:
  mountWithWorkloadIdentityToken: "true"
  clientID: "<受控識別的 client ID>"

幫客戶上雲時，最常看到的壞習慣就是把儲存體金鑰寫進 Kubernetes Secret，然後所有服務共用。平常沒事，哪天某個小服務被打穿，整個儲存體帳號的資料都跟著曝光。

這次更新讓「一個應用程式一個身分、只給需要的權限」在 Azure Files 上也做得到。新專案我會直接這樣設；舊叢集如果還沒到 1.35.0，可以先把升級排進計畫，再一個服務一個服務地把金鑰拿掉。另外文件範例的掛載權限是 0777，正式環境記得依需求收緊。

工作負載身分是什麼？

讓 Kubernetes 裡的某個應用程式（透過 ServiceAccount）換到一個 Microsoft Entra 身分，再用這個身分去存取 Azure 資源，不用在程式或設定裡放密碼或金鑰。

以前不是已經可以不用金鑰嗎？

以前可以用受控識別掛載，但權限是掛在節點上，同一台節點的程式拿到的權限一樣大。這次改成 Pod 等級，可以只讓需要的應用程式碰得到那份檔案。

有什麼使用條件？

官方文件寫明需要 AKS 1.35.0 以上的 Linux 節點，叢集要開啟 OIDC 簽發者，並替受控識別建立同盟身分認證，再在儲存類別或 PV 設定 mountWithWorkloadIdentityToken。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。