Single Privileged Service Account in Kubernetes Config Connector Enables GCP Org Takeover
The root cause of this vulnerability is a design flaw in Google Kubernetes Config Connector (KCC), where all cloud resource operations are executed through a single, overly privileged service account with organization-wide permissions. This violates the principle of least privilege, meaning any user who can create resources in a Kubernetes namespace can indirectly leverage that shared service account to manipulate IAM policies at the highest organizational level. The attack surface is particularly dangerous because it requires only limited, seemingly innocuous Kubernetes namespace access — a permission level many operators might grant without concern. This matters because a complete GCP organization compromise could expose all projects, data, and services under that umbrella, turning a misconfigured YAML file into a catastrophic breach.
Tactical Insight
Immediate actions
- Audit all existing KCC deployments to identify namespaces with untrusted or overly broad user access and restrict them immediately.
- Apply Google's latest KCC patches or configuration guidance to enforce per-namespace Workload Identity bindings instead of a shared service account.
- Review and revoke any IAM policies that were created via KCC by unauthorized or unexpected principals.
Long-term improvements
- Enforce least-privilege service account design by binding unique, scoped service accounts to each Kubernetes namespace rather than sharing a single high-privileged account.
- Implement admission controllers (e.g., OPA/Gatekeeper) to validate and restrict the types of KCC resources users can create within a namespace.
- Establish a formal review process for any Kubernetes YAML that provisions cloud IAM or organization-level resources before it is applied to production.
Detection measures
- Enable GCP Audit Logs and Cloud Monitoring alerts for any IAM policy changes at the organization or folder level, especially those originating from KCC service accounts.
- Continuously scan Kubernetes clusters for anomalous resource types or privilege-escalating configurations using tools such as Falco or Checkov.
- Implement SIEM correlation rules to flag sequences of Kubernetes namespace activity followed by elevated GCP IAM mutations.