Kubernetes Config Connector Flaw Allows Full Google Cloud Takeover

Security researchers have identified a privilege escalation vulnerability in Google Kubernetes Config Connector (KCC) that could allow a user with limited cluster access to seize control of an entire Google Cloud Platform (GCP) organisation.

The technique, dubbed “ConfigConfusion” by researcher Justin O’Leary, exploits a “confused deputy” problem. This occurs when a high-privilege service account—in this case, the KCC service account—is used to carry out instructions from a lower-privilege user without verifying if that user has the authority to perform the requested cloud action.

The Mechanics of ConfigConfusion

In many GitOps workflows, developers use KCC to manage cloud resources by submitting YAML configuration files to a Kubernetes cluster. To simplify management, platform teams often grant the KCC service account broad permissions, such as roles/owner or roles/resourcemanager.organizationAdmin, across the entire organisation.

Under this configuration, an attacker with permission to create IAMPolicyMember resources within a single Kubernetes namespace can bypass standard security boundaries. By submitting a specific YAML file, the attacker can instruct KCC to grant their own service account high-level IAM roles. Because KCC possesses the necessary authority, Google Cloud IAM accepts the request, unaware that the original trigger came from an unauthorised user.

The vulnerability stems from a disconnect between two separate authorisation systems. Kubernetes Role-Based Access Control (RBAC) only validates whether a user can create a resource within the cluster; it does not evaluate the potential impact on Google Cloud. Conversely, Google Cloud IAM only checks if the KCC service account has the authority to make the change, failing to verify the identity of the Kubernetes user who initiated the request.

Vendor Response and Mitigation

Google has responded to the findings by stating that KCC is working as designed. The company noted that the risk is a result of configuration choices made by administrators, specifically the decision to grant KCC organisation-level permissions while allowing developers to manage IAM resources within managed namespaces.

To mitigate the risk of ConfigConfusion, security experts recommend the following measures:

• Implement Namespaced Mode: Use a separately scoped Google service account for each Kubernetes namespace to limit the potential blast radius.
• Apply the Principle of Least Privilege: Review and remove broad roles like roles/owner from the KCC service account unless they are strictly required for operations.
• Restrict IAM Resource Creation: Limit the ability to create IAMPolicyMember, IAMPolicy, and IAMPartialPolicy resources to approved platform or infrastructure teams.
• Monitor IAM Changes: Audit organisation-level IAM modifications made by KCC, particularly those occurring outside of established GitOps workflows.