"KCC is working as designed," Google said in response to the vulnerability researchers called ConfigConfusion.
How GitOps and Google Kubernetes Config Connector hand off cloud authority
GitOps operators let developers declare cloud resources as Kubernetes YAML and hand the work to a controller inside the cluster. In Google Cloud, that controller is Google Kubernetes Config Connector (KCC), typically running in Google Kubernetes Engine (GKE). Developers write resources — for example an IAMPolicyMember that grants a service account a role on a project — commit them to Git, and apply them to the cluster. KCC watches those files and calls the corresponding Google Cloud APIs to create or update the resources.
The design intent is explicit: developers never hold Google Cloud credentials. KCC authenticates to Google Cloud through Workload Identity using a single Google service account controlled by the platform team (often called the KCC GSA). Because KCC may manage resources across projects, folders, or an entire organization, that account is commonly given broad roles such as roles/owner or roles/resourcemanager.organizationAdmin.
ConfigConfusion: one Kubernetes YAML can yield organization ownership
Security researcher Justin O'Leary coined the term ConfigConfusion to describe how a user with limited cluster access can gain broad Google Cloud authority through KCC. If an attacker has access to a Kubernetes namespace watched by KCC and permission to create IAMPolicyMember resources there, they can submit a single YAML that asks KCC to grant their Google service account an organization-level role — even without any Google Cloud credentials of their own.
The source provides the attack example as a one-command YAML:
apiVersion: iam.cnrm.cloud.google.com/v1beta1 kind: IAMPolicyMember metadata: name: escalation namespace: my-team spec: member: "serviceAccount:attacker@attacker-project.iam.gserviceaccount.com" role: roles/owner resourceRef: apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1 kind: Organization external: "123456789"
KCC reads that resource and calls Google Cloud IAM using its own service account. If the KCC service account is permitted to set that binding, Google Cloud accepts the change — and the attacker gains control of the organization without ever holding a Google credential.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogTwo authorization systems and a missing linkage
The vulnerability arises from the separated checks performed by Kubernetes RBAC and Google Cloud IAM. Kubernetes RBAC decides whether a user may create an IAMPolicyMember resource in a namespace; it does not and cannot interpret the downstream Google Cloud consequences of that resource. Google Cloud IAM evaluates whether the KCC service account may set the requested IAM binding; it does not know which Kubernetes user caused KCC to make the API call. As the source puts it, KCC is a classic confused deputy: it has broad authority and acts on instructions from users with less authority, without checking whether they should be allowed to use that authority.
Google's stance, why the check is hard, and recommended mitigations
Google's response — "KCC is working as designed" — frames ConfigConfusion as a configuration outcome: administrators chose to give KCC an organization-level service account and to allow developers to create IAMPolicyMember resources in KCC-managed namespaces. The documentation, the source notes, does not make the interaction between those choices obvious.
Implementing a per-request check that verifies the Kubernetes user's corresponding Google Cloud permission before KCC acts would close the gap, but KCC is designed specifically so users need no Google Cloud identity. Looking up the requester's permissions per reconciliation would add authorization checks and extra API calls to every reconciliation cycle, undermining the GitOps model KCC provides.
Consequently, Google recommends reducing the authority KCC holds rather than changing how it authorizes each request. The source lists a practical checklist administrators should follow:
- Use namespaced mode so each namespace uses a separately scoped Google service account where possible.
- Review KCC's IAM roles at project, folder, and organization levels.
- Remove broad roles such as roles/owner and roles/resourcemanager.organizationAdmin unless strictly required.
- Limit permission to create IAMPolicyMember, IAMPolicy, and IAMPartialPolicy resources to approved platform or infrastructure teams.
- Monitor folder- and organization-level IAM changes made by KCC, particularly those outside the approved GitOps workflow.
The material also compares platform approaches: AWS Controllers for Kubernetes (ACK) separates controllers and scopes an IAM role per service, while Azure Service Operator v2 allows each namespace to use a separate managed identity — both techniques reduce blast radius even though the confused-deputy risk remains conceptually similar across platforms.
What this means for platform teams, developers, and attackers
Platform teams should treat KCC configuration decisions as linked: granting namespace-level creation rights for IAM resources and assigning broad Google Cloud roles to the KCC service account together create an exploitable escalation path. Tightening KCC's Google service account permissions and restricting who can submit IAM resources are concrete, source-recommended controls.
Developers benefit from the credential-free GitOps model but must be aware that namespace permissions in Kubernetes can carry unseen Google Cloud authority when KCC is present; teams should restrict IAM-related resource creation to approved infrastructure personnel.
Attackers need only Kubernetes write access in a watched namespace and the ability to create an IAMPolicyMember resource to exploit the condition; the exploit requires no Google Cloud credentials if KCC's service account already holds the authority to make the requested change.
Either condition on its own can be managed, but together they create a privilege-escalation path that requires no Google Cloud credentials to exploit — a configuration gap framed by design choices and documentation that doesn't highlight the linkage. Administrators who run KCC in environments with organization-level permissions should assume the risk exists and apply the checklist controls as an immediate mitigation.
