Kubernetes Access Could Let Users Escalate to Google Cloud Organization Owner Through KCC

Aug 25, 2026 · Original article ↗

Summary

Config Connector can use its broadly privileged Google Cloud service account to carry out IAM changes requested by Kubernetes users, potentially letting users with namespace access grant themselves organization-wide roles.

Key points

KCC performs Google Cloud operations through its own service account, so Google Cloud does not see which Kubernetes user initiated a request.
A user who can create IAMPolicyMember resources in a KCC-managed namespace may be able to grant themselves any role the KCC service account can assign, including organization-wide owner access.
The issue is a confused deputy risk created by separate Kubernetes RBAC and Google Cloud IAM checks; each authorizes its own side without checking the full request.
The attack requires namespace access and permission to create the relevant IAM resources, combined with a KCC service account that has broad IAM authority.
The article says Google considers KCC to be operating as designed and recommends limiting the operator’s permissions rather than changing its authorization model.
Suggested mitigations include using namespaced mode with separately scoped service accounts, removing unnecessary broad roles, restricting IAM resource creation, and monitoring high-level IAM changes.
The article notes that AWS Controllers for Kubernetes and Azure Service Operator offer ways to scope controller permissions or identities, reducing potential impact.

Article Details

Attack Vectors: A user with permission to create IAMPolicyMember resources in a KCC-managed Kubernetes namespace can induce KCC to grant that user Google Cloud IAM roles available to KCC's service account, potentially including organization-level ownership.
The privilege-escalation path requires a KCC service account with broad Google Cloud IAM permissions and broad write access to KCC-managed namespaces; the attacker does not need Google Cloud credentials.
Defensive Notes: Use KCC namespaced mode with a separately scoped Google service account for each namespace.
Review KCC's IAM roles at project, folder, and organization levels; remove broad roles such as roles/owner and roles/resourcemanager.organizationAdmin unless strictly required.
Limit permission to create IAMPolicyMember, IAMPolicy, and IAMPartialPolicy resources to approved platform or infrastructure teams.
Monitor folder- and organization-level IAM changes made by KCC, particularly changes outside the approved GitOps workflow.
The article notes that AWS Controllers for Kubernetes separates controllers and scopes roles by service, while Azure Service Operator v2 can use separate managed identities per namespace; both approaches can limit potential impact.