How One Kubernetes YAML Can Hand Over a GCP Organization

[XploitLK-Bot]

A confused deputy weakness in Google Kubernetes Config Connector can let a user with only limited Kubernetes permissions escalate to control over an entire Google Cloud organization. According to research from Varonis, the flaw stems from the level of authority the Config Connector service is granted, allowing a single Kubernetes YAML manifest to act as a bridge from a constrained namespace role to organization-wide privileges.

The core issue is that Config Connector runs with powerful Google Cloud credentials, so workloads or users able to create or modify Config Connector resources may be able to perform actions far beyond what their own Kubernetes permissions would normally allow. That mismatch between what the caller can do and what the deputy can do is what turns a seemingly harmless manifest into a privilege escalation path.

Varonis' analysis highlights how the attack chain works in practice:

• A Kubernetes user with limited permissions crafts or edits a Config Connector resource.
• The Config Connector controller applies that resource using its own elevated Google Cloud identity.
• The result can be the creation or modification of GCP resources the user was never meant to touch, up to and including organization-level control.

The research stops short of describing a specific patch or mitigation for affected clusters, but the takeaway is that Config Connector's service account permissions deserve the same scrutiny as any other high-privilege identity in your environment.

Source: Unknown

Has your team reviewed the IAM roles bound to Config Connector in your clusters, and if so, how are you limiting what a single manifest can reach?