One YAML File Could Hand Over Your Entire Google Cloud Organization

Robert Moore · 2026-09-23

### The Confused Deputy Problem in Google Kubernetes Config Connector Picture this: a developer with limited access to your Kubernetes cluster writes a single YAML file. That file, when applied, doesn't just deploy a pod or a service—it quietly escalates their privileges until they control your entire Google Cloud organization. Sounds like a stretch? It's not. Security researchers at Varonis recently detailed exactly how this can happen through a confused deputy vulnerability in Google Kubernetes Config Connector. And if you're running GKE with Config Connector enabled, you need to pay attention. ### What Is Config Connector and Why Does It Matter? Config Connector is a Kubernetes add-on that lets you manage Google Cloud resources—like storage buckets, IAM policies, and even project-level settings—using Kubernetes-style YAML manifests. It's a powerful tool for platform teams who want a single control plane for both Kubernetes and GCP. But that power comes with a catch: Config Connector runs with a highly privileged service account. If an attacker can trick it into acting on their behalf, they can inherit that privilege. That's the classic "confused deputy" problem. The deputy (Config Connector) has the authority, but it can be fooled into using that authority for someone who shouldn't have it. ### How a Single YAML File Opens the Door Here's the scary part: you don't need cluster-admin rights to exploit this. A user with permission to create or modify certain Kubernetes resources—like Custom Resource Definitions (CRDs) or Config Connector custom resources—can craft a YAML file that instructs Config Connector to grant them organization-level IAM roles. Once that YAML is applied, Config Connector dutifully executes the request using its own service account, which often has broad permissions across the GCP organization. In plain English: a low-privilege user can become an organization admin in minutes, all without triggering obvious alarms. ### What You Can Do About It So, how do you protect yourself? Start by auditing who has permission to create or modify Config Connector resources in your clusters. Limit those permissions to only the most trusted platform engineers. Next, follow the principle of least privilege for the Config Connector service account itself—don't give it organization-wide admin if it only needs access to a few projects. Also, enable audit logging for both Kubernetes and GCP IAM changes, and set up alerts for suspicious role bindings. Finally, keep an eye on Google's documentation and security bulletins. As cloud-native tools evolve, so do the attack vectors. A proactive stance today can save you from a very bad day tomorrow. > "The most dangerous vulnerabilities aren't the ones that break in—they're the ones that quietly walk through the front door using your own keys." ### The Bottom Line Kubernetes and GCP are incredibly powerful together, but that power demands respect. A single YAML file should never be a skeleton key to your entire cloud empire. By understanding how confused deputy attacks work and tightening your permissions, you can keep your organization safe—and sleep a little better at night.