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?