How One Kubernetes YAML Can Hand Over a GCP Organization
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.
AI Analysis
Technical 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.
Potential 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.
Mitigation Recommendations
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. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance.
How One Kubernetes YAML Can Hand Over a GCP Organization
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.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
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.
Potential 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. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance.
Technical Details
- Classification
- {"confidence":0.3,"severitySource":"default","classifier":"rss-v2"}
- Article Source
- {"url":"https://www.bleepingcomputer.com/news/security/how-one-kubernetes-yaml-can-hand-over-a-gcp-organization/","fetched":true,"fetchedAt":"2026-09-24T08:42:56.071Z","wordCount":1727}
Threat ID: 6ab4e4ebf7a7c541061acae6
Added to database: 09/24/2026, 08:52:59 UTC
Last enriched: 09/24/2026, 08:53:07 UTC
Last updated: 09/25/2026, 01:43:41 UTC
Views: 15
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.