A critical flaw in Google's Kubernetes Config Connector allows a user with only basic Kubernetes permissions to take over an entire Google Cloud Platform organization, according to security researchers from Varonis.
The vulnerability exploits a "confused deputy" scenario involving the connector's default service account. This account is designed to manage GCP resources via Kubernetes custom resources but is granted an overly permissive default IAM role, giving it sweeping authority to act across GCP resources.
Varonis, in a report detailed by BleepingComputer on September 28, explained that an attacker needs only the ability to create or modify resources within a Kubernetes cluster—a common task for many developers. From this position, they can deploy a malicious Kubernetes YAML file. The Config Connector, unable to distinguish this malicious request from a legitimate one, will execute the privileged GCP commands defined in the file.
This leads to immediate privilege escalation, handing the attacker full control of the target's GCP organization. With this level of access, they could exfiltrate sensitive data, alter infrastructure, or establish persistent backdoors, resulting in a complete cloud environment compromise. The attack requires no pre-existing GCP permissions, making it a potent risk from an initial, limited foothold.
For organizations, particularly those in Hong Kong accelerating hybrid and multi-cloud adoption, this incident underscores a critical lesson. As enterprises deploy workloads on managed Kubernetes services like Google Kubernetes Engine (GKE), the attack surface grows. The principle of least privilege must extend beyond human users to the powerful service accounts and automation tools driving cloud-native infrastructure.
A clear mitigation strategy is available. The primary recommendation is to audit the default IAM role attached to the Config Connector service account and replace it with a custom, narrowly-scoped role that grants only the necessary permissions—a fundamental zero-trust practice.
As a secondary defense, continuous monitoring for anomalous activity from the Config Connector account is essential. Any unexpected create, update, or delete operations should trigger immediate investigation. This layered approach helps mitigate both known and potential future misuse.
While this vulnerability targets Google's tool, the underlying security pattern is a universal concern. Researchers are now examining analogous cloud management tools, such as Azure Arc and AWS Controllers for Kubernetes, for similar risks, signaling a broader area for scrutiny within the cloud-native ecosystem.
根據 Varonis 安全研究員的報告，Google Kubernetes Config Connector 中存在一個嚴重漏洞，讓僅具備基本 Kubernetes 權限的使用者即可接管整個 Google Cloud Platform 組織。
此漏洞利用了與連接器預設服務帳號相關的「混淆代理人」情境。該帳號旨在透過 Kubernetes 自訂資源管理 GCP 資源，但被賦予了權限過大的預設 IAM 角色，使其獲得在 GCP 資源上廣泛操作的權限。
Varonis 在 9 月 28 日由 BleepingComputer 報導的詳細報告中解釋，攻擊者只需具備在 Kubernetes 叢集內建立或修改資源的能力——這是許多開發人員的常見任務。在此基礎上，他們可以部署惡意的 Kubernetes YAML 檔案。Config Connector 無法區分此惡意請求與合法請求，將會執行該檔案中定義的特權 GCP 命令。
這導致即時的權限提升，使攻擊者獲得目標 GCP 組織的完全控制權。擁有此等存取權限後，他們可以竊取敏感數據、修改基礎設施或建立持久性後門，導致整個雲端環境被入侵。此攻擊不需要預先存在的 GCP 權限，使其從初始的有限立足點即構成重大風險。
對企業組織，尤其是香港正加速採用混合及多雲架構的企業而言，此事件凸顯了一個關鍵教訓。隨著企業在 Google Kubernetes Engine (GKE) 等託管 Kubernetes 服務上部署工作負載，攻擊面隨之擴大。最小權限原則必須超越人類使用者，延伸至驅動雲端原生基礎設施的強大服務帳號及自動化工具。
現已有明確的緩解策略。首要建議是審計附加至 Config Connector 服務帳號的預設 IAM 角色，並將其替換為僅授予必要權限的自訂、範圍嚴格的角色——這是零信任架構的基本實踐。
作為第二層防禦，持續監控 Config Connector 帳號的異常活動至關重要。任何非預期的建立、更新或刪除操作都應觸發即時調查。此分層方法有助於緩解已知及潛在的未來濫用。
雖然此漏洞針對 Google 的工具，但底層安全模式是普遍關注的問題。研究人員現正檢查類似的雲端管理工具，如 Azure Arc 和 AWS Controllers for Kubernetes，以尋找類似風險，標誌著雲端原生生態系統中更廣泛的審查領域。