新聞

雲端服務將Kubernetes與身分及存取管理（IAM）串接後，權限檢查若只確認執行操作的服務身分，卻沒有回頭核對提出要求的使用者，可能讓原本權限有限的人間接動用更高權限。資安研究員Justin O'Leary日前先後公開Azure Backup for AKS與Google Cloud Config Connector兩個案例，指出使用者可能藉由雲端服務持有的權限，操作自己無法直接存取的Kubernetes叢集或Google Cloud資源。

Azure案例可能把雲端備份管理權限擴大為Kubernetes叢集管理權限，Google Cloud案例則可能把Kubernetes單一命名空間內建立特定資源的權限，擴大為Google Cloud組織層級的IAM權限。不過，微軟與Google均認為相關情況建立在客戶既有的高權限設定之上，不構成產品漏洞，兩案目前也沒有CVE編號。

Justin O'Leary將兩案歸類為混淆代理人問題，認為原因在於Kubernetes權限與雲端IAM之間的落差。雲端服務執行備份、還原或資源設定時，通常會使用系統身分取得所需權限，要是系統只確認該身分有權執行，卻未核對提出要求的使用者是否具備相應資格，高權限服務就可能替低權限使用者完成原本不能進行的操作。

在Azure案例中，只在備份保存庫擁有Backup Contributor角色、沒有AKS叢集權限的使用者，過去可能啟用目標叢集的備份功能，使Azure透過Trusted Access自動把cluster-admin權限授予備份擴充元件，再利用備份讀取敏感資料，或透過還原程序部署惡意工作負載。

Justin O'Leary後續測試發現，系統增加了原先沒有的權限檢查，原本的操作方式已無法成功，因此認為微軟曾在未公告的情況下修補。微軟則表示，相關操作本來就需要客戶環境既有的管理權限，產品行為符合設計，也未因這項研究修改產品。

Google Cloud案例則可能讓Kubernetes內的有限權限擴大到Google Cloud組織。Justin O'Leary指出，要是Config Connector使用的服務帳號具備組織層級管理權限，只有Kubernetes單一命名空間操作權的使用者，也可能要求連接器修改組織IAM政策，把擁有者權限授予自己。

Google表示，這種情況必須先讓Config Connector服務帳號持有組織管理權限，攻擊者也必須先進入客戶環境，因此屬於權限配置與最小權限原則未落實的問題。Justin O'Leary則反駁，Google文件本身提供把擁有者角色（roles/owner）授予Config Connector服務帳號的組織層級設定範例，他認為，問題不在服務帳號持有高權限，而在於Config Connector未核對提出要求的Kubernetes使用者是否具有修改目標Google Cloud資源IAM政策的權限。