This issue has been assessed as high severity. Review affected configurations immediately.
What has been reported
This is not a breaking story. The research surfaced in mid-2026 and we are covering it because the fix sits entirely in your configuration. Sources we opened on 27 October 2026:
- Varonis, “It’s Not a Bug, It’s a Feature: Kubernetes Access to GCP Org Admin” (page shows “Last updated August 25, 2026”). It names the research ConfigConfusion and credits Justin O’Leary.
- Aviatrix’s summary (vendor marketing, published 28 July 2026), which also mentions an Azure Kubernetes Service backup flaw (Backup Contributor to cluster-admin). It gives no mechanism for either flaw.
We could not open the Dark Reading original (HTTP 403) or the researcher’s own write-up. No CVE ID appears in either page we opened. Per Varonis, Google’s response was that Config Connector (KCC) is “working as designed”. Sources disagree on Microsoft’s handling and on bounty details, so we leave those out.
The mechanism
Config Connector runs in a GKE cluster and converts Kubernetes YAML into Google Cloud resources. Per Varonis, every Google Cloud call is made by KCC’s own Google service account (the KCC GSA), not the identity of whoever submitted the YAML.
If that service account holds a role such as roles/owner or roles/resourcemanager.organizationAdmin, anyone who can create an IAMPolicyMember in a KCC-watched namespace can ask KCC to grant a role on an Organization resource. Kubernetes RBAC only checks that the user may create the object. Google Cloud IAM only checks that the KCC GSA may set the binding. Nothing asks whether this user should get that outcome. The attacker needs no Google Cloud credentials.
Inference, not from the sources: any controller that reconciles cloud IAM from cluster objects (not only KCC) deserves the same review.
Step 1: find what your KCC service account can do
List the roles held by the KCC service account at the organization (replace the placeholders):
gcloud organizations get-iam-policy ORG_ID \
--flatten="bindings[].members" \
--filter="bindings.members:serviceAccount:KCC_GSA_EMAIL" \
--format="table(bindings.role)"Repeat with gcloud resource-manager folders get-iam-policy FOLDER_ID and gcloud projects get-iam-policy PROJECT_ID. Any roles/owner, roles/resourcemanager.organizationAdmin or roles/resourcemanager.projectIamAdmin at a high level is the red flag.
Step 2: find who can create IAM resources in the cluster
Check a specific user or group for the dangerous kinds in a KCC namespace:
kubectl auth can-i create iampolicymembers.iam.cnrm.cloud.google.com \
-n TEAM_NAMESPACE [email protected]
kubectl auth can-i create iampolicies.iam.cnrm.cloud.google.com \
-n TEAM_NAMESPACE [email protected]
kubectl auth can-i create iampartialpolicies.iam.cnrm.cloud.google.com \
-n TEAM_NAMESPACE [email protected]Also search for broad grants such as edit or admin ClusterRoles bound in KCC namespaces, since those typically include custom resources:
kubectl get rolebindings,clusterrolebindings -A -o wide | grep -E 'edit|admin'Step 3: reduce the deputy’s authority
Varonis recommends the following, which we have restated:
- Use namespaced mode with a separate Google service account per namespace, so one team’s namespace cannot spend another team’s authority.
- Remove high-level roles from the KCC service account unless strictly required, and grant narrow roles on specific projects instead.
- Restrict who can create IAM kinds. Give teams a Role that excludes them, and allow them only for the platform team:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: team-kcc-resources
namespace: TEAM_NAMESPACE
rules:
- apiGroups: ["storage.cnrm.cloud.google.com"]
resources: ["storagebuckets"]
verbs: ["get", "list", "watch", "create", "update"]Listing resources explicitly (rather than using *) keeps iampolicymembers out by default. Confirm with the kubectl auth can-i checks above.
Step 4: monitor IAM changes made by KCC
Alert on organization and folder IAM changes by the KCC service account. A starting Cloud Logging filter:
protoPayload.methodName="SetIamPolicy"
protoPayload.authenticationInfo.principalEmail="KCC_GSA_EMAIL"Treat any hit outside your GitOps pipeline as an incident. One secondary source claims the attack is hidden from audit logs. We could not verify that, so test your own alerting by making a benign change and confirming the log entry appears.
Does this apply to AWS and Azure?
Varonis notes that AWS Controllers for Kubernetes separates controllers by service with scoped IAM roles, and Azure Service Operator v2 lets each namespace use its own managed identity. It adds that neither removes the underlying confused deputy risk. We did not test either.
Unverified
No exploitation in the wild: no evidence found as of 2026-10-27 in the Varonis and Aviatrix pages we opened. That is not proof of absence.