Google Cloud Config Connector Can Turn Kubernetes Namespace Access Into Organization-Level Admin Access

Google Kubernetes Config Connector (KCC) helps organizations manage Google Cloud resources through Kubernetes and GitOps. However, a misconfigured KCC deployment can allow users with limited Kubernetes access to exercise the Google Cloud permissions assigned to KCC—including organization-level administrative privileges.

The issue, known as configuration confusion, can create a privilege-escalation path that does not require attackers to possess Google Cloud credentials.

The problem with Google Cloud service account keys

When a developer creates a cloud resource such as a database, storage bucket, or virtual machine, they need credentials to authenticate to the cloud provider. In Google Cloud, this often means using a service account key: a JSON file that proves the user’s identity and defines what they are allowed to do.

The problem is that service account keys are files. They can be copied, emailed, accidentally committed to a Git repository, left on a laptop, or forgotten.

When someone leaves a team, an organization may not know which keys that person had. Tracking and rotating credentials across dozens of developers creates a significant operational burden and security risk.

In industry terms, this is secret sprawl: cloud credentials are distributed across machines, pipelines, and codebases in ways that are difficult to audit and even harder to remove.

How GitOps removes developer cloud credentials

The Kubernetes community’s solution is to use GitOps operators, also known as controllers:

1. Developers create YAML configuration files that describe the required resources, commit them to Git, and apply them to a Kubernetes cluster.
2. Controllers running inside the cluster read those files and create or update cloud resources on the developers’ behalf.

Developers no longer need direct cloud credentials. Instead, the controller authenticates to the cloud provider using its own identity.

Google’s version of this system is Google Kubernetes Config Connector, commonly called KCC. It typically runs inside a Google Kubernetes Engine (GKE) cluster, monitors Kubernetes resources that describe Google Cloud resources, and calls the corresponding Google Cloud APIs to create or update them.

For example, a developer who wants an application to read objects from a Cloud Storage bucket can submit an IAMPolicyMember resource:

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: my-binding
  namespace: my-team
spec:
  member: "serviceAccount:[email protected]"
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    external: "my-project"

KCC authenticates to Google Cloud through Workload Identity using a Google service account, commonly referred to as a KCC GSA, managed by the platform team.

Because KCC may manage multiple projects, folders, or infrastructure across an organization, its service account can have broad permissions, including roles/owner or roles/resourcemanager.organizationAdmin.

When a developer submits a resource, KCC retrieves it and calls Google Cloud IAM. The requested permissions are created without the developer ever handling Google Cloud credentials.

This setup works as intended: developer credentials are removed, infrastructure is declared in Git, and the platform team manages one service account instead of dozens. However, the same design can introduce a serious authorization gap.

How namespace access can become organization-owner access

KCC performs Google Cloud operations through its own service account, regardless of which Kubernetes user submitted the resource. If that account has organization-level permissions, users with limited access to a Kubernetes namespace may be able to exercise those permissions indirectly.

This technique is called configuration confusion and was discovered by security researcher Justin O’Leary.

The attack requires:

1. Access to a Kubernetes namespace monitored by KCC.
2. Permission to create IAMPolicyMember resources within that namespace.
3. No Google Cloud credentials or permissions of the attacker’s own.

If these conditions exist, an attacker may grant a service account any Google Cloud IAM role that KCC is allowed to assign. If KCC has organization-level permissions, that can include roles/owner across the organization.

The attack can be initiated by submitting a Kubernetes resource such as:

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: escalation
  namespace: my-team
spec:
  member: "serviceAccount:[email protected]"
  role: roles/owner
  resourceRef:
    apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
    kind: Organization
    external: "123456789"

The attacker applies the YAML through Kubernetes. KCC reads the resource and requests the IAM change from Google Cloud using its own service account. Because KCC has permission to make the change, Google Cloud honors the request.

The attacker can then control resources in the Google Cloud organization without directly holding Google Cloud credentials.

Two authorization systems, but no end-to-end check

The issue exists because two separate authorization systems handle different parts of the request:

1. Kubernetes RBAC controls what users can do inside the cluster. It may determine that a user is allowed to create an IAMPolicyMember resource in a particular namespace, but it does not understand what that resource can do in Google Cloud.
2. Google Cloud IAM controls what service accounts can do in Google Cloud. When KCC creates an IAM binding, Google Cloud checks whether KCC’s service account has permission to make the change. It does not know which Kubernetes user initiated the request or whether that user should be allowed to perform the operation.

Kubernetes knows about the resource being created in the cluster, while Google Cloud sees only the KCC service account making the change. KCC can therefore accept requests from users with limited Kubernetes access and execute them using permissions those users do not have in Google Cloud.

This is an example of the confused deputy problem: a highly privileged service performs actions at the direction of a less privileged user without adequately verifying whether that user should be allowed to request them.

Removing cloud credentials from developers is a useful and intentional design decision. However, it also removes the direct link between the developer’s Kubernetes identity and the Google Cloud permissions used on that developer’s behalf. Once KCC processes the request, Google Cloud sees KCC—not the person who triggered the change.

Google says Config Connector is working as designed

Google’s response to ConfigConfusion was that KCC is working as designed.

The administrator chooses to give KCC an organization-level service account and chooses to allow developers to create IAMPolicyMember resources in namespaces managed by KCC. From Google’s perspective, these are configuration decisions, and KCC fulfills the submitted requests.

The instructions are technically accurate, and KCC performs the operations as configured. The problem is that the documentation does not clearly explain the relationship between the two decisions.

Administrators often think separately about which Kubernetes resource types a team can create and what the KCC service account can do in Google Cloud. With KCC, those permissions are connected. Allowing a team to create IAMPolicyMember resources can also give that team a way to use KCC’s Google Cloud permissions.

Because it can be difficult to determine exactly which permissions KCC needs, administrators may grant organization-level access for convenience. This does not necessarily reflect poor management; the resulting authority gap is a consequence of an easily overlooked design relationship.

Why is the Config Connector issue difficult to fix?

The most obvious fix would be to verify that the Kubernetes user submitting a resource also has the corresponding Google Cloud permissions before KCC processes the request.

That approach depends on the Kubernetes user having a Google Cloud identity. KCC is designed to operate without requiring one. Giving every user a corresponding Google Cloud identity would undermine the model, while checking the requester’s permissions for every resource would add authorization checks and extra API calls to each reconciliation cycle.

As a result, Google’s recommended mitigations focus on reducing the privileges available to KCC rather than changing how every request is authorized.

The same risk exists in AWS and Azure

This authentication and authorization problem is not unique to KCC. Infrastructure operators that accept instructions from one identity and execute them through another can create a similar gap. The potential impact depends on how much authority the operator has and how easily that authority can be restricted.

1. AWS Controllers for Kubernetes (ACK): Controllers are separated by service. IAM, Amazon S3, and Amazon EC2 can each use their own controller and IAM role scoped to that service. If a user controls the S3 controller’s request path, they may influence S3 resources but cannot make IAM changes when the controller lacks those permissions.
2. Azure Service Operator v2: Each Kubernetes namespace can use a separate managed identity. This gives administrators a practical way to limit permissions by namespace rather than placing an entire operator’s authority behind one identity.

Neither approach eliminates the underlying confused-deputy risk, but both can reduce the potential damage by limiting operator privileges before malicious requests are processed.

How to secure Google Config Connector

To mitigate the risk, organizations need to limit both sides of the authorization gap: what KCC’s service account can do in Google Cloud and which Kubernetes users can submit and process sensitive resources.

Use the following checklist:

• Does KCC use namespace mode with separate, scoped Google service accounts for each namespace?
• Have KCC’s IAM roles been reviewed at the project, folder, and organization levels?
• Have broad roles such as roles/owner and roles/resourcemanager.organizationAdmin been removed unless they are strictly necessary?
• Is the ability to create IAMPolicyMember, IAMPolicy, and IAMPartialPolicy resources limited to authorized platform or infrastructure teams?
• Are folder- and organization-level IAM changes made by KCC being monitored, particularly changes outside approved GitOps workflows?

The vulnerable configuration combines broad write access to KCC-managed namespaces with organization-level permissions assigned to the KCC service account.

Either condition can be managed independently, but combining them creates a privilege-escalation path that does not require Google Cloud credentials to exploit.

Sponsored and written by Varonis.