Config Connector lets you manage your Google Cloud Platform (GCP) resources using Kubernetes Custom Resource Definitions (CRDs).
Let’s see it in action. Imagine you want to create a GCP Cloud Storage bucket. Normally, you’d use gcloud or the GCP Console. With Config Connector, you define it as a Kubernetes StorageBucket object:
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
name: my-unique-gcp-bucket-12345
spec:
location: US-CENTRAL1
lifecycle:
rule:
- action:
type: Delete
condition:
age: 30
When you apply this YAML to your Kubernetes cluster where Config Connector is installed, it translates this StorageBucket object into a call to the GCP Storage API. Config Connector’s controllers watch for these CRDs and reconcile their state with actual GCP resources. If the bucket doesn’t exist, it creates it. If the location in your YAML changes, Config Connector updates the GCP bucket.
This approach brings the power of Kubernetes’ declarative management, GitOps workflows, and RBAC to your cloud infrastructure. Instead of managing separate tools and permissions for your Kubernetes workloads and your cloud resources, you have a single pane of glass. Your infrastructure becomes code, versioned in Git, and deployed via kubectl apply.
Here’s how it works internally. Config Connector is deployed as a set of controllers within your Kubernetes cluster. These controllers watch for specific CRDs (like StorageBucket, PubSubTopic, SQLInstance, etc.) that represent GCP resources. When you create, update, or delete one of these CRDs, the corresponding Config Connector controller detects the change. It then makes the appropriate API calls to GCP to reflect that desired state. For example, the StorageBucket controller handles the creation and management of Google Cloud Storage buckets, while the PubSubTopic controller manages Pub/Sub topics.
The core problem Config Connector solves is the operational overhead of managing cloud resources separately from application deployments. Developers and operators often have distinct workflows and permissions for Kubernetes applications and for underlying cloud infrastructure. This leads to context switching, potential drift between desired and actual infrastructure state, and a complex access control model. By treating GCP resources as Kubernetes objects, you can:
- Centralize Management: Use
kubectland Kubernetes RBAC to manage both application deployments and cloud infrastructure. - Enable GitOps: Store your GCP resource definitions in Git, enabling version control, auditability, and automated deployments.
- Improve Developer Experience: Developers can provision the cloud resources their applications need directly through Kubernetes manifests, without needing direct GCP IAM permissions for those resources.
- Enforce Policies: Leverage Kubernetes admission controllers and policy engines (like Gatekeeper) to enforce organizational policies on GCP resource creation.
The specific levers you control are within the spec of each CRD. For a StorageBucket, you might define location, storageClass, versioning, lifecycle rules, and IAM policies. For a PubSubTopic, you’d control messageStoragePolicy and IAM policies. For a SQLInstance, you’d configure databaseVersion, settings, and ipConfiguration. The exact fields available are documented for each specific resource type.
Config Connector leverages the Kubernetes API machinery to watch for changes to these custom resources and then translates those changes into calls to the Google Cloud APIs. It’s essentially an API translator and reconciliation loop. If a resource is modified outside of Kubernetes (e.g., directly in the GCP console), Config Connector will detect the drift during its next reconciliation and revert it to the state defined in your Kubernetes manifests.
When you define IAM policies for your GCP resources using Config Connector, you’re creating IAMPolicy or IAMBinding CRDs. These objects mirror the structure of GCP IAM policies, allowing you to grant roles to members (users, service accounts, groups) for specific GCP resources. This is powerful because it means you can manage who has access to your cloud resources using the same Kubernetes RBAC patterns you use for your cluster.
The most surprising thing about Config Connector is how deeply it integrates the Kubernetes control plane with GCP’s resource management. It doesn’t just provision GCP resources; it owns them from the perspective of your Kubernetes cluster. This means that if you delete a StorageBucket CRD from Kubernetes, Config Connector will delete the actual GCP bucket. If you try to manually delete the GCP bucket, Config Connector will likely recreate it because its desired state is still defined in your cluster.
The next step is to explore how to manage more complex, interconnected GCP resources like networking components or databases and understand how to handle drift detection and remediation.