---
cuppy_hub: gcp
cuppy_path: reference/iac/config-connector.md
cuppy_section: docs
cuppy_doc: BTN1-5S6S
cuppy_doc_uuid: 75e6352c-a2e5-4d0c-884b-7d1c30dde361
cuppy_permalink: https://cuppy.io/gcp/d/BTN1-5S6S
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/iac/config-connector
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: badfd0b6b01da8c86e97cafa157c9dfaafed681f5c801c14642e79420e12fa8f
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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

```yaml
apiVersion: cnrm.cloud.google.com/v1beta1
kind: StorageBucket
```

Kinds 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:

1. **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).
2. **Kubernetes RBAC and Google Cloud IAM are two separate gates.** Being allowed to `kubectl apply` the
   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`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->