NewsPublished 23 Sep 2026

How One Kubernetes YAML Can Hand Over a GCP Organization

Source Bleeping Computer

Description

A security issue exists in Google Kubernetes Config Connector (KCC) where a Kubernetes user with limited permissions can escalate privileges to gain control over an entire Google Cloud organization. This occurs because KCC uses a single Google Cloud service account with broad permissions to perform actions on behalf of Kubernetes users, without verifying if the user is authorized for those actions in Google Cloud. This confused deputy problem allows a user who can create IAMPolicyMember resources in a Kubernetes namespace to assign themselves any Google Cloud IAM role that KCC's service account can grant, including organization owner. Google acknowledges this behavior as intended design, but it creates a significant risk if KCC's service account has overly broad permissions and Kubernetes RBAC is not tightly controlled.

Impact

An attacker with limited Kubernetes namespace permissions can escalate privileges to gain full control over the entire Google Cloud organization by creating IAMPolicyMember resources that assign themselves organization-level roles. This bypasses Google Cloud IAM restrictions because KCC uses a single service account with broad permissions to apply changes. The attacker does not need any Google Cloud credentials or permissions of their own. This can lead to complete compromise of the organization's cloud resources and administrative control.

Defensive guidance

Google considers this behavior as working as designed and attributes the risk to configuration decisions. To mitigate, administrators should avoid granting organization-level permissions to the KCC service account unless absolutely necessary. Kubernetes RBAC should be tightly restricted to prevent users from creating IAMPolicyMember resources in namespaces managed by KCC. Monitoring and auditing Kubernetes RBAC permissions and KCC service account roles is critical. There is no indication of an official patch or fix; remediation depends on careful configuration and access control.

Summary

Google Kubernetes Config Connector (KCC) runs inside a GKE cluster and manages Google Cloud resources by applying Kubernetes YAML manifests. KCC authenticates to Google Cloud using a single service account (KCC GSA) that often has organization-level permissions. Kubernetes RBAC controls which users can create resources like IAMPolicyMember in namespaces, but does not check Google Cloud permissions. When a user with permission to create IAMPolicyMember resources submits a manifest, KCC uses its own service account to apply the IAM change in Google Cloud. Because Google Cloud only sees KCC's service account, it does not verify the original Kubernetes user's permissions. This confused deputy problem allows privilege escalation from limited Kubernetes namespace access to full Google Cloud organization ownership. Google states this is working as designed, reflecting configuration choices by administrators. The issue arises from the disconnect between Kubernetes RBAC and Google Cloud IAM authorization models and the broad permissions often granted to the KCC service account.

References

bleepingcomputer.com/news/security/how-one-kubernetes-yaml-can-hand-over-a-gcp-organization/ (opens in a new tab)

Community reviews

Loading reviews…

Description

AI analysisMachine-generated, updated 24 Sep 2026, 08:53 UTC

References

Community reviews

Related threats