Stealing a car

When a developer needs to create a cloud resource — a database, a storage bucket, or a virtual machine — they need credentials to authenticate to the cloud provider. In Google Cloud, that often means a service account key: a JSON file that proves who they are and what they're allowed to do.

The problem with service account keys is that they're files. Files get copied, emailed, accidentally committed to Git repositories, left on laptops, and forgotten.

When someone leaves a team, the organization doesn't always know which keys they had. Tracking and rotating credentials across dozens of developers becomes a significant operational burden and security risk.

The industry term for this is secret sprawl: cloud credentials scattered across machines, pipelines, and codebases in ways that are difficult to audit and even harder to remove.

How GitOps removed the credentials

The Kubernetes community's solution to this is a GitOps operator (also known as a controller):

  1. A developer writes YAML configuration files describing the resources they need, commits them to Git, and applies them to a Kubernetes cluster.
  2. A controller running inside the cluster reads those files and creates or updates the cloud resources on the developer's behalf.

The key point: developers end up with no cloud credentials at all. The controller authenticates on their behalf, using its own.

Google's version of this system is Google Kubernetes Config Connector (KCC), which typically runs inside a Google Kubernetes Engine (GKE) cluster. KCC watches for configuration files describing Google Cloud resources and calls the corresponding Google Cloud API to create or update them.

A developer who wants to grant an application permission to read objects from a storage bucket could submit an IAMPolicyMember resource:

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

KCC authenticates to Google Cloud through Workload Identity, using a Google service account controlled by the platform team — often called the KCC GSA. Because KCC may manage infrastructure across multiple projects, folders, or an entire organization, this account can be given broad roles such as role/owner or roles/resourcemanager.organizationAdmin.

When the developer submits the resource, KCC picks it up and calls Google Cloud IAM. The permission is created, and the developer never touches a Google Cloud credential.

Subscribe: State of Cybercrime
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
 name: escalation
 namespace: my-team
spec:
 member: "serviceAccount:attacker@attacker-project.iam.gserviceaccount.com"
 role: roles/owner
 resourceRef:
 apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
 kind: Organization
 external: "123456789"