Config Connector — Google Cloud resources as Kubernetes objects, the identity that reconciles them, and the two modes
The Kubernetes add-on that manages Google Cloud resources as custom resources. What it is, the apiVersion group and the kind names, the two installation routes, namespaced against cluster mode, and the fact that most surprises an operator: reconciliation runs as the Config Connector service account, never as the person who applied the manifest.
markdownreferencev1BTN1-5S6Sstage: buildtrust: officialfamily: iacservice: config-connectorinterface: iacconfig connectorcnrm.cloud.google.com/v1beta1ComputeInstanceStorageBucketPubSubTopicconfig controllernamespaced modecluster modeGKE add-on
Config Connector
1. What it is
"Config Connector is an open source Kubernetes add-on that lets you manage Google Cloud resources through Kubernetes."
It installs CRDs and controllers, so a Google Cloud resource becomes a Kubernetes object that a controller
reconciles. If your delivery system is already kubectl and GitOps, this removes the separate Terraform
pipeline.
2. The object shape
apiVersion: cnrm.cloud.google.com/v1beta1
kind: StorageBucketKinds the page names: ComputeInstance, StorageBucket, PubSubTopic. The pattern is the Google Cloud
resource's name in Kubernetes casing, under the cnrm.cloud.google.com group.
3. Three ways to get it
| Route | Note |
|---|---|
| GKE add-on | the managed installation on a cluster you already run |
| manual installation | you install the CRDs and controllers yourself |
| Config Controller | the page names it as an alternative deployment option — a managed cluster pre-loaded with the tooling |
4. The identity fact, which is the one to internalise
"Reconciliation executes using the identity of the Config Connector IAM service account, not the identity of the human user or service account that submitted the manifest."
Two consequences, both of which show up as confusing failures:
- A permission error names the Config Connector service account, not the engineer. Diagnosing it with
your own principal in Policy Troubleshooter answers the wrong question
(guides/identity/fix-permission-denied.md step 2 takes the principal from the error, which is why).
- Kubernetes RBAC and Google Cloud IAM are two separate gates. Being allowed to
kubectl applythe
manifest says nothing about whether the resource can be created; the reconciler's own IAM decides that. Budget both in a design, and in an estimate.
5. The two modes
- namespaced mode — resources are namespace-scoped, and a namespace can be tied to its own Google Cloud
identity. This is what multi-tenant clusters want.
- cluster mode — resources are cluster-wide, with one reconciling identity.
The choice is an IAM boundary, not a layout preference: namespaced mode is how one cluster manages resources in several projects without any namespace holding the others' permissions.
6. An absence, recorded
The overview page read here does not name the deletion-policy annotation that decides whether deleting the Kubernetes object also deletes the Google Cloud resource. Do not assume either behaviour. Before you let Config Connector manage anything stateful, establish the deletion behaviour from the product's own resource reference and write it into the design. Guessing this wrong deletes a database.
Next: reference/iac/errors.md; the cross-cloud view — Config Connector against AWS Controllers for
Kubernetes and Azure Service Operator — in guides/parity/iac.md.