Security1 publisher2 min readPublished
Config Connector turns namespace write access into roles/owner on a GCP organization
Justin O'Leary's ConfigConfusion technique turns on the fact that Google's Config Connector makes every cloud call with its own service account, so a tenant who can create one IAMPolicyMember inherits whatever that account is allowed to grant.
The Watch · Security desk
What happened
- Google Kubernetes Config Connector runs inside a GKE cluster, reads YAML describing cloud resources, and calls the Google Cloud APIs itself, so developers never hold a service account key.
- It authenticates through Workload Identity as a platform-team service account that is often granted roles/owner or organizationAdmin, because it manages resources across projects, folders or a whole organization.
- Security researcher Justin O'Leary found that the controller makes every cloud call as that account no matter which Kubernetes user submitted the resource, and named the technique ConfigConfusion.
- An attacker who can create IAMPolicyMember resources in a watched namespace, holding no Google Cloud credentials, can grant themselves any role the controller's service account is permitted to assign.
- A single IAMPolicyMember naming the attacker's service account, roles/owner and the organization as the target is accepted by Google Cloud IAM, handing the attacker control of the organization.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Namespace RBAC now decides who can become owner of the cloud organization, so a cluster tenancy boundary is carrying an IAM boundary it was not designed to enforce.
- capability Because the path needs no stolen key and no cloud identity, secret scanning, key rotation and credential inventories all miss it.
- cost Containing this means running project-scoped controllers instead of one organization-wide one, which puts back the account sprawl the pattern was adopted to remove.
- decision Responders investigating an IAM change have to join cluster records to cloud logs, because the cloud audit trail names the controller's service account.
Config Connector reads the IAMPolicyMember, then calls Google Cloud IAM as the platform team's service account, and IAM sees a request from an account that is allowed to make it [6][9]. At no stage does the chain compare the submitter to the permission being requested. The only access check the attacker passes is the Kubernetes RBAC rule that lets them create resources in that namespace [10].
How far the attacker gets depends on one grant. They can assign exactly the roles the controller's service account is permitted to assign [8]. With roles/owner or organizationAdmin held at the organization node, that set includes the organization [4]. With a service account scoped to a single project, the organization-level request fails [11].
Then there is attribution. On the Google Cloud side the binding was created by the platform team's service account, because that is the identity every Config Connector operation uses [6]. The name of the Kubernetes user who submitted the YAML stays in the cluster [12].
The GitOps flow also widens who counts as a namespace tenant. Developers commit these files to Git and the cluster applies them [2], so write access to the repository path that syncs into a watched namespace is equivalent to direct access to the namespace [13].
Config Connector solves a real credential problem. Service account keys are JSON files, and files get copied, emailed, committed to Git repositories, and left on laptops [1]. Taking them off developer machines concentrates the permissions in one in-cluster identity, and the control on that identity is a namespace RBAC rule about which resource kinds a tenant may create [4][7].
Narrowing the controller's account is the containment. Part of the reason platform teams adopt this is one service account to govern instead of dozens [15]; splitting an organization-wide controller into project-scoped ones multiplies the identities and the rotation work back toward what the pattern was meant to remove [16].
The BleepingComputer write-up does not include a disclosure date, a CVE, or a comment from Google [14].
What to watch
- Whether Google adds an admission-time check tying the submitting Kubernetes identity to the cloud role being requested.
- Whether a CVE or vendor advisory is assigned to ConfigConfusion, which would put a date on the disclosure.
- Public write-ups showing the same escalation against other cloud resource controllers that write IAM under their own credentials.