Kubernetes 借雲端 IAM 做嘢：Azure、Google 權限爭議點查

一個要求，其實有兩個身分

Kubernetes 接駁雲端服務之後，一次操作通常牽涉兩個角色：發出要求嘅用戶，同真正呼叫雲端 API 嘅服務身分。後者要有足夠權限先做到備份、還原或者改資源設定，不過系統一旦淨係確認服務身分有權，冇再核對最初嗰位用戶，權限有限嘅人就可能借佢隻手做多咗。安全圈叫呢種情況做 confused deputy（混淆代理人），麻煩位正正係 Kubernetes RBAC 同雲端 IAM 各自都可以運作正常，但兩層接起上嚟就出現落差。

Azure 爭議集中喺 AKS 備份

研究員 Justin O’Leary 話，過往一個只喺 Backup vault 擁有 Backup Contributor、本身冇 AKS 權限嘅帳戶，可以啟用目標叢集備份，令 Azure Backup 經 Trusted Access 取得 Kubernetes 管理權限。研究員話，攻擊者可能讀到備份入面嘅敏感資料，亦可以喺還原期間放入惡意 workload。佢其後再試，舊有做法已經會報錯，指系統欠缺 Trusted Access role binding，而且亦多咗權限檢查，所以佢判斷微軟改過系統行為；微軟就堅持呢個場景本身已有客戶環境管理權限，屬預期設計，冇因研究而改產品，亦冇發 CVE。

微軟而家嘅官方文件列明，Trusted Access 要用 role binding 明確連結來源服務同 AKS，AKS 備份亦要先啟用呢段信任關係。呢點至少證明管理員唔應該當 Backup Contributor 只係「睇住備份」咁簡單：呢個角色可以管理備份操作，而備份服務背後又會接觸叢集資料。實務上要逐個 AKS 列出 Trusted Access role binding，核對來源 vault、獲授角色同建立時間；Backup Contributor 亦要收窄到指定 vault 或 resource group，臨時工作可配合 PIM 限時開權。

Google 個案由 Kubernetes CRD 改到雲端 IAM

Google Cloud 呢邊涉及 Config Connector。佢容許團隊用 Kubernetes custom resource 管理 Google Cloud 資源，當用戶建立 IAMPolicyMember，controller 會用自己嘅服務帳戶改 IAM policy。研究員指，如果呢個服務帳戶本身有 organization 層級權限，而 namespace 用戶又可以建立相關資源，用戶即使冇 Google Cloud IAM 權限，都可能提交外部 organization ID，再叫 Config Connector 將高權角色加畀指定帳戶。Google 回應話，場景先決條件包括服務帳戶早已有組織管理權限，同攻擊者已經進入客戶環境，所以屬客戶設定同最小權限問題，唔構成產品漏洞。

Google 呢個反駁講中咗一半：高權限服務帳戶確實係必要條件，冇嗰份權，Config Connector 都做唔到越界操作。不過研究指出嘅設計落差仍然值得處理，因為 Kubernetes 用戶獲准建立一個 CRD，實際效果可以等同修改另一套 IAM。用 cluster mode 共用一個服務帳戶尤其要小心；Google 官方文件提供嘅 namespaced mode，可以每個 namespace 配獨立服務帳戶，將權限分開。管理員亦應限制邊啲角色可以 create、patch 或 delete IAMPolicyMember、IAMPolicy 同 IAMPartialPolicy，避免萬用 verb、萬用 resource，同 organization 層級 roles/owner 一類過闊授權。

Audit log 要兩邊一齊睇

研究員特別提醒，Google Cloud audit log 顯示嘅執行者可能只係 Config Connector 服務帳戶，單睇雲端一邊，未必即時知道邊個 Kubernetes 用戶提交咗要求。處理方法係保留 GKE Kubernetes audit log，再按時間、資源同服務帳戶，同 Cloud Audit Logs 入面嘅 IAM policy 變更互相對照；Azure 亦要同時翻查 Activity Log、Trusted Access role binding 變動同 AKSAuditAdmin。後者會記錄 Kubernetes API 嘅修改要求，而且 Microsoft 文件確認呢類 resource log 要先設 Diagnostic Settings，未開就唔會自動保存。

爭議未完，設定可以而家查

iThome 報道將兩案歸納成 Kubernetes 同雲端 IAM 之間嘅權限落差，亦清楚交代微軟同 Google 都否認漏洞定性。現有資料未足以將所有 AKS 或 Config Connector 部署講成受影響，兩條攻擊鏈亦各自有先決權限，暫時冇證據顯示香港環境曾受特定攻擊。不過用緊相關服務嘅公司 IT 同平台團隊，可以即刻盤點高權服務身分、跨 namespace 委派、Trusted Access 綁定同 audit log 覆蓋；等供應商同研究員爭完名詞，先至補權限清單就太遲。

參考來源

• iThome — Azure與Google Cloud服務遭指可越權操作，微軟與Google否認構成漏洞 — original report
• OLearySec：Azure Backup for AKS 研究 — 研究員公開嘅 Azure 攻擊鏈、測試結果同披露時間線。
• OLearySec：Config Connector IAM 授權繞過研究 — 研究員公開嘅 Google Cloud 技術重現、先決權限同爭議焦點。
• Microsoft Learn：AKS Trusted Access — 核對 Trusted Access role binding、服務身分同官方授權模型。
• Microsoft Learn：監察 AKS — 核對 AKS audit log、Diagnostic Settings 同記錄保存方式。
• Google Cloud：Config Connector IAM 權限設定 — 核對 cluster mode、namespaced mode 同服務帳戶權限分隔。
• Google Cloud：GKE RBAC 最佳做法 — 核對 namespace、service account、萬用權限同最小權限建議。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。