[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f_VQ8xMasLl779Bq-KjD1dnRQICQR9p6R8fNllVh4tpA":3},{"article":4,"iocs":56},{"id":5,"title":6,"slug":7,"summary":8,"ai_summary":9,"brief":10,"full_text":11,"url":12,"image_url":13,"published_at":14,"ingested_at":15,"relevance_score":16,"entities":17,"category_id":33,"category":34,"article_tags":38},"7373db2b-f2de-4729-ac82-7c329228d9df","How One Kubernetes YAML Can Hand Over a GCP Organization","how-one-kubernetes-yaml-can-hand-over-a-gcp-organization-721edf","A Kubernetes user with limited permissions can potentially gain control of an entire Google Cloud organization by exploiting the authority granted to Google Kubernetes Config Connector. Varonis explains how this confused deputy problem can turn a single Kubernetes YAML file into a path to organization-wide privilege escalation. [...]","A vulnerability in Google Kubernetes Config Connector (KCC) allows a user with limited Kubernetes namespace access to potentially gain control of an entire Google Cloud organization. This 'ConfigConfusion' issue arises because KCC performs all operations using a single, highly-privileged service account, enabling attackers to indirectly escalate their permissions by creating specific IAM policy resources.","Kubernetes Config Connector vulnerability allows limited users to gain GCP organization control.","How One Kubernetes YAML Can Hand Over a GCP Organization Sponsored by Varonis September 23, 2026 10:01 AM 0 When a developer needs to create a cloud resource — a database, a storage bucket, or a virtual machine — they need credentials to authenticate to the cloud provider. In Google Cloud, that often means a service account key: a JSON file that proves who they are and what they're allowed to do. The problem with service account keys is that they're files. Files get copied, emailed, accidentally committed to Git repositories, left on laptops, and forgotten. When someone leaves a team, the organization doesn't always know which keys they had. Tracking and rotating credentials across dozens of developers becomes a significant operational burden and security risk. The industry term for this is secret sprawl: cloud credentials scattered across machines, pipelines, and codebases in ways that are difficult to audit and even harder to remove. How GitOps removed the credentials The Kubernetes community's solution to this is a GitOps operator (also known as a controller): A developer writes YAML configuration files describing the resources they need, commits them to Git, and applies them to a Kubernetes cluster. A controller running inside the cluster reads those files and creates or updates the cloud resources on the developer's behalf. The key point: developers end up with no cloud credentials at all. The controller authenticates on their behalf, using its own. Google's version of this system is Google Kubernetes Config Connector (KCC), which typically runs inside a Google Kubernetes Engine (GKE) cluster. KCC watches for configuration files describing Google Cloud resources and calls the corresponding Google Cloud API to create or update them. A developer who wants to grant an application permission to read objects from a storage bucket could submit an IAMPolicyMember resource: apiVersion: iam.cnrm.cloud.google.com\u002Fv1beta1 kind: IAMPolicyMember metadata: name: my-binding namespace: my-team spec: member: \"serviceAccount:my-app@my-project.iam.gserviceaccount.com\" role: roles\u002Fstorage.objectViewer resourceRef: kind: Project external: \"my-project\" KCC authenticates to Google Cloud through Workload Identity, using a Google service account controlled by the platform team — often called the KCC GSA. Because KCC may manage infrastructure across multiple projects, folders, or an entire organization, this account can be given broad roles such as role\u002Fowner or roles\u002Fresourcemanager.organizationAdmin. When the developer submits the resource, KCC picks it up and calls Google Cloud IAM. The permission is created, and the developer never touches a Google Cloud credential. Every namespace shares KCC's single organization-level identity This setup works well for its intended purpose: no developer credentials, everything declared in Git, and one service account for the platform team to control instead of dozens. The credential sprawl problem is solved. Continue your journey to reduce data risk at your company Listen to State of Cybercrime, Varonis’ monthly podcast to learn about high-profile cyberattacks, shadow IT, supply chain incidents, and AI security risks. Subscribe to the series and catch every future episode. Subscribe: State of Cybercrime When namespace access becomes an organization owner The same setup, however, creates a new problem. KCC performs every Google Cloud operation through its own service account, regardless of which Kubernetes user submitted the resource. If that account has organization-level permissions, a user with limited cluster access can exercise those permissions indirectly. This technique is called ConfigConfusion, discovered by security researcher Justin O'Leary. If an attacker has: Access to a Kubernetes namespace watched by KCC. Permission to create IAMPolicyMember resources in that namespace. No Google Cloud credentials or permissions of their own. They can grant themselves any Google Cloud IAM role that KCC's service account is permitted to assign — including roles\u002Fowner on the entire organization. The attack itself is one command: apiVersion: iam.cnrm.cloud.google.com\u002Fv1beta1 kind: IAMPolicyMember metadata: name: escalation namespace: my-team spec: member: \"serviceAccount:attacker@attacker-project.iam.gserviceaccount.com\" role: roles\u002Fowner resourceRef: apiVersion: resourcemanager.cnrm.cloud.google.com\u002Fv1beta1 kind: Organization external: \"123456789\" The attacker applies the YAML through Kubernetes. KCC reads it and requests the IAM change from Google Cloud using its own service account, which has permission to make it, so the request is accepted. The attacker now controls the Google Cloud organization — without ever holding a Google Cloud credential. One IAMPolicyMember turns namespace access into organization ownership Two authorization systems, one missing check To understand why this works, look at the two separate authorization systems handling the request. Kubernetes RBAC controls what a user can do inside the cluster. It asks: \"Is this user allowed to create an IAMPolicyMember resource in this namespace?\" If yes, it allows the operation. It knows nothing about Google Cloud and doesn't ask what the resource will do there. Google Cloud IAM controls what a service account can do in Google Cloud. When KCC calls Google Cloud to create the binding, it asks: \"Does KCC's service account have permission to set this IAM binding?\" If yes, it allows the operation. Google Cloud doesn't know which Kubernetes user triggered the request, and doesn't check whether that user should have been allowed to request it. Each system checks its half of the request; nobody checks the whole As a result, Kubernetes only sees the resource being created inside the cluster, and Google Cloud only sees KCC's service account making the change. KCC can receive a request from a user with limited access and carry it out using permissions that user doesn't have in Google Cloud. This is known as a confused deputy problem: KCC has broad authority and acts on instructions from users with less authority, without checking whether they should be able to use it. The design decision that removes cloud credentials from developers is useful and intentional. But it also removes the link between a developer's Kubernetes identity and the Google Cloud permissions used on their behalf. When KCC acts, Google Cloud sees KCC — not the person who triggered the request. Google calls it a feature Google's response to ConfigConfusion was that KCC is working as designed. The administrator chose to give KCC an organization-level service account, and chose to allow developers to create IAMPolicyMember resources in KCC-managed namespaces. From Google's perspective, those are configuration decisions, and KCC carries out the request it was given. That explanation is technically accurate, and KCC does exactly what it's configured to do. The issue is that the documentation doesn't make the relationship between these two decisions obvious. Most administrators think about them separately: which Kubernetes resource types can this team create, and what can KCC's service account do in Google Cloud? In KCC, the two are connected — giving a team permission to create an IAMPolicyMember resource can also give that team a way to use KCC's Google Cloud authority. Working out the exact permissions KCC needs is difficult, so granting organization-level access is often easier. It doesn't necessarily reflect poor administration — it's the natural outcome of a design that doesn't make the resulting authority gap visible. Why it's hard to fix The most obvious fix would be to check whether the Kubernetes user who submitted a resource has the corresponding Google Cloud permission before carrying out the request. That check depends on the Kubernetes user having a Google Cloud identity — but KCC is designed so that they don't need one. Giving each user a corresponding identity would undermine the model KCC was built to","https:\u002F\u002Fwww.bleepingcomputer.com\u002Fnews\u002Fsecurity\u002Fhow-one-kubernetes-yaml-can-hand-over-a-gcp-organization\u002F","https:\u002F\u002Fwww.bleepstatic.com\u002Fcontent\u002Fposts\u002F2026\u002F09\u002F22\u002Fscrewdriver-stealing-card.jpg","2026-09-23T14:01:11+00:00","2026-09-23T20:00:45.290141+00:00",8,[18,21,23,26,28,30],{"name":19,"type":20},"Kubernetes Config Connector","product",{"name":22,"type":20},"Google Kubernetes Engine",{"name":24,"type":25},"GitOps","technology",{"name":27,"type":25},"IAM",{"name":29,"type":25},"Kubernetes",{"name":31,"type":32},"Google","vendor","c70f3a41-2f0c-4608-870d-b8cbcd8be076",{"id":33,"icon":35,"name":36,"slug":37},null,"Cloud Security","cloud-security",[39,44,49,51],{"category":40},{"id":41,"icon":35,"name":42,"slug":43},"26b0b636-0e31-4db1-bffb-61bdf9f20a58","Supply Chain","supply-chain",{"category":45},{"id":46,"icon":35,"name":47,"slug":48},"80544778-fabb-4dcd-aa35-17492e5dcf4f","Vulnerabilities","vulnerabilities",{"category":50},{"id":33,"icon":35,"name":36,"slug":37},{"category":52},{"id":53,"icon":35,"name":54,"slug":55},"e7b231c8-5f79-4465-8d38-1ef13aea5a14","Threat Intelligence","threat-intelligence",[57,61,64],{"type":58,"value":59,"context":60},"mitre_attack","T1078.004","Cloud Accounts: Service Account exploitation",{"type":58,"value":62,"context":63},"T1538","Cloud Instance Metadata API",{"type":58,"value":65,"context":66},"T1207","Service Account Token Manipulation"]