{"id":533,"date":"2026-04-14T10:04:34","date_gmt":"2026-04-14T10:04:34","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-config-connector-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management\/"},"modified":"2026-04-14T10:04:34","modified_gmt":"2026-04-14T10:04:34","slug":"google-cloud-config-connector-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-config-connector-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-access-and-resource-management\/","title":{"rendered":"Google Cloud Config Connector Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Access and resource management"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Access and resource management<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Config Connector is a Google Cloud service that lets you manage Google Cloud resources using Kubernetes-style, declarative configuration. You apply Kubernetes manifests, and Config Connector creates, updates, and deletes real Google Cloud resources by calling Google Cloud APIs on your behalf.<\/p>\n\n\n\n<p>In simple terms: <strong>if your team already uses Kubernetes workflows (namespaces, RBAC, GitOps, <code>kubectl apply<\/code>)<\/strong>, Config Connector lets you manage cloud infrastructure\u2014like Cloud Storage buckets, Pub\/Sub topics, IAM bindings, and more\u2014without switching to a separate infrastructure tool. Your Kubernetes cluster becomes a control plane for Google Cloud resources.<\/p>\n\n\n\n<p>Technically, Config Connector installs Kubernetes Custom Resource Definitions (CRDs) and controllers. Each CRD represents a Google Cloud resource type. When you apply a resource manifest, the controller reconciles the desired state into the actual state in Google Cloud using authenticated API calls. The controller continuously checks for drift and updates status fields and conditions back into the Kubernetes resource.<\/p>\n\n\n\n<p>The problem it solves: <strong>teams need consistent, auditable, repeatable infrastructure management<\/strong>. Config Connector helps standardize resource provisioning and governance by using Kubernetes-native patterns (declarative config, reconciliation loops, RBAC, namespaces) to manage Google Cloud resources\u2014especially valuable for platform engineering and access\/resource management programs.<\/p>\n\n\n\n<blockquote>\n<p>Naming note: <strong>Config Connector<\/strong> is an active Google Cloud offering. It\u2019s closely related to <strong>Config Controller<\/strong> (a managed Google Cloud service that provides a hosted Kubernetes control plane for infrastructure management). Do not confuse Config Connector with GitOps products like <strong>Config Sync<\/strong> (which syncs Kubernetes configs from Git repositories).<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Config Connector?<\/h2>\n\n\n\n<p><strong>Official purpose (what it\u2019s for)<\/strong><br\/>\nConfig Connector enables you to manage Google Cloud resources through Kubernetes APIs. It exposes Google Cloud resources as Kubernetes objects so you can provision and operate infrastructure using Kubernetes tooling and workflows.<\/p>\n\n\n\n<p><strong>Core capabilities<\/strong>\n&#8211; <strong>Kubernetes CRDs for Google Cloud resources<\/strong> (for example, Storage buckets, IAM policy bindings, Pub\/Sub topics\u2014resource coverage varies; verify the supported resource list in official docs).\n&#8211; <strong>Continuous reconciliation<\/strong>: desired state in Kubernetes is continuously reconciled against actual state in Google Cloud.\n&#8211; <strong>Status reporting<\/strong>: resource readiness, errors, and observed state are reported in Kubernetes via conditions\/events.\n&#8211; <strong>Access and resource management workflows<\/strong>: manage IAM-related resources (for example, service accounts and policy bindings) using Kubernetes RBAC and namespaces for separation of duties.<\/p>\n\n\n\n<p><strong>Major components<\/strong>\n&#8211; <strong>CRDs (CustomResourceDefinitions)<\/strong>: one CRD per supported Google Cloud resource kind.\n&#8211; <strong>Controller(s)<\/strong>: watch Kubernetes resources and call Google Cloud APIs to reconcile.\n&#8211; <strong>Credentials \/ identity integration<\/strong>: typically uses <strong>Workload Identity<\/strong> on GKE (recommended), or other supported identity methods depending on environment (verify the current supported authentication modes).\n&#8211; <strong>Kubernetes namespaces and RBAC<\/strong>: used to partition responsibility across teams and projects (especially in namespaced mode).<\/p>\n\n\n\n<p><strong>Service type<\/strong>\n&#8211; A <strong>Kubernetes extension\/controller<\/strong> that runs in a Kubernetes cluster (commonly GKE).\n&#8211; Often used as part of broader <strong>platform engineering<\/strong> and <strong>infrastructure-as-code<\/strong> practices.\n&#8211; Related managed option: <strong>Config Controller<\/strong> (hosted control plane) which uses Config Connector concepts.<\/p>\n\n\n\n<p><strong>Scope and locality<\/strong>\n&#8211; Config Connector runs <strong>inside your Kubernetes cluster<\/strong>; its \u201cscope\u201d is effectively the cluster where it\u2019s installed.\n&#8211; The Google Cloud resources it manages can span:\n  &#8211; <strong>Project scope<\/strong> (most common)\n  &#8211; Potentially <strong>folder\/org scope<\/strong> for certain resource types (requires appropriate permissions; verify supported resources and constraints)\n&#8211; It is not a \u201cregional\u201d Google Cloud API service in the same way as Cloud Storage or Pub\/Sub; rather, it is a controller that calls Google Cloud APIs (which may be global\/regional depending on the resource type).<\/p>\n\n\n\n<p><strong>How it fits into the Google Cloud ecosystem<\/strong>\n&#8211; Works with:\n  &#8211; <strong>Google Kubernetes Engine (GKE)<\/strong> as the most common runtime.\n  &#8211; <strong>IAM<\/strong> (identity and access management) to authorize reconciliation actions.\n  &#8211; <strong>Cloud Audit Logs<\/strong> to record all API actions performed.\n  &#8211; <strong>Cloud Logging\/Monitoring<\/strong> for cluster and controller visibility.\n&#8211; Complements (not replaces) tools like:\n  &#8211; <strong>Terraform<\/strong> for multi-cloud IaC\n  &#8211; <strong>gcloud<\/strong> and Console for ad-hoc operations\n  &#8211; <strong>Policy Controller\/Gatekeeper<\/strong> for policy enforcement (commonly paired for governance; verify product names and availability in your environment)<\/p>\n\n\n\n<p>Official documentation entry point (start here):<br\/>\nhttps:\/\/cloud.google.com\/config-connector\/docs\/overview<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Config Connector?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardize provisioning<\/strong> across teams using a consistent API and workflow (Kubernetes).<\/li>\n<li><strong>Speed up delivery<\/strong> by letting application\/platform teams use the same pipeline patterns for both app deployments and infrastructure.<\/li>\n<li><strong>Improve auditability<\/strong>: changes are captured as Git commits and Kubernetes events, and Google Cloud API calls are captured in Audit Logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Declarative desired state<\/strong> and <strong>controller-based reconciliation<\/strong> reduce configuration drift.<\/li>\n<li><strong>Kubernetes-native primitives<\/strong>:<\/li>\n<li>namespaces for multi-tenancy patterns<\/li>\n<li>RBAC to limit who can create\/change infrastructure objects<\/li>\n<li>admission policy for guardrails (for example, deny public buckets)<\/li>\n<li>Works well for teams already invested in Kubernetes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>GitOps-friendly<\/strong>: store infrastructure definitions in Git and sync to the cluster.<\/li>\n<li>Unified tooling: <code>kubectl<\/code>, CI pipelines, policy tooling, Kubernetes resource status\/conditions.<\/li>\n<li>Supports repeatable environment creation (dev\/test\/prod) through manifests and overlays.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons (Access and resource management)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enables <strong>structured IAM administration<\/strong> using Kubernetes RBAC + scoped namespaces.<\/li>\n<li>Works with <strong>Workload Identity<\/strong> (recommended on GKE) to avoid long-lived service account keys.<\/li>\n<li>Google Cloud API calls are auditable with <strong>Cloud Audit Logs<\/strong>.<\/li>\n<li>Enables \u201cpolicy as code\u201d patterns when paired with Kubernetes admission controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes controller model scales operationally: controllers can handle many resources and continuously reconcile.<\/li>\n<li>Supports <strong>multi-team scaling<\/strong> through namespaces and RBAC (a common pattern: one namespace per project\/team).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Config Connector<\/h3>\n\n\n\n<p>Choose Config Connector when:\n&#8211; You run GKE or Kubernetes as a platform and want <strong>one control plane<\/strong> for both workloads and Google Cloud resources.\n&#8211; You want <strong>strong separation of duties<\/strong> using Kubernetes RBAC and namespaces.\n&#8211; You want to implement <strong>resource governance<\/strong> with admission control and GitOps.\n&#8211; You want to manage a significant portion of Google Cloud resources declaratively and continuously.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose Config Connector<\/h3>\n\n\n\n<p>Avoid or reconsider Config Connector when:\n&#8211; You don\u2019t operate Kubernetes reliably (controllers need a stable cluster).\n&#8211; You need broad, complete coverage of every Google Cloud resource type immediately (support varies; verify the supported resources list).\n&#8211; You require <strong>multi-cloud<\/strong> IaC from a single tool (Terraform\/Crossplane might be a better fit).\n&#8211; You need to provision foundational infrastructure before Kubernetes exists (you still need a \u201cbootstrap\u201d step).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Config Connector used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>SaaS and technology<\/strong>: platform teams managing standardized projects, IAM, and shared services.<\/li>\n<li><strong>Financial services and healthcare<\/strong>: auditability and policy enforcement are valuable (subject to compliance requirements; verify with your compliance team).<\/li>\n<li><strong>Retail and media<\/strong>: many teams\/projects with standardized patterns (buckets, Pub\/Sub, service accounts).<\/li>\n<li><strong>Public sector<\/strong>: structured access\/resource management with audit trails.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building internal developer platforms (IDPs).<\/li>\n<li>DevOps\/SRE teams standardizing operations.<\/li>\n<li>Security engineering teams implementing IAM and guardrails as code.<\/li>\n<li>Application teams that self-provision approved resources via namespaces.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes-based workloads that need adjacent Google Cloud resources:<\/li>\n<li>GCS buckets for artifacts\/data<\/li>\n<li>Pub\/Sub topics and subscriptions<\/li>\n<li>Service accounts and IAM bindings<\/li>\n<li>Secret Manager secrets (where supported; verify)<\/li>\n<li>Cloud SQL instances (where supported; verify)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>GitOps<\/strong> architectures: Git repo \u2192 CI \u2192 cluster sync \u2192 Config Connector \u2192 Google Cloud APIs.<\/li>\n<li><strong>Multi-project landing zones<\/strong>: namespaces mapped to projects, with central policies and templates.<\/li>\n<li><strong>Shared services<\/strong>: central clusters that manage shared IAM, logging sinks, or networking components (resource support and permissions permitting).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: typically used with:<\/li>\n<li>strict RBAC<\/li>\n<li>dedicated namespaces per team\/project<\/li>\n<li>policy enforcement<\/li>\n<li>reliable cluster operations and backup\/DR considerations<\/li>\n<li><strong>Dev\/test<\/strong>: fast environment creation, experimentation with standard patterns, training labs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are practical scenarios where Config Connector is commonly a good fit. Resource availability varies\u2014verify each resource kind in the official resource reference.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Self-service Cloud Storage buckets per team<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams need buckets with consistent naming, labels, and security settings.<\/li>\n<li><strong>Why Config Connector fits<\/strong>: Buckets can be declared as Kubernetes objects; policy can enforce \u201cno public access.\u201d<\/li>\n<li><strong>Example<\/strong>: Each team has a namespace; applying a <code>StorageBucket<\/code> manifest creates an encrypted bucket with uniform access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) IAM access provisioning via Kubernetes RBAC<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Central IAM team is a bottleneck; teams need controlled self-service access.<\/li>\n<li><strong>Why it fits<\/strong>: Teams can manage approved IAM bindings via CRDs while cluster admins enforce RBAC\/policy constraints.<\/li>\n<li><strong>Example<\/strong>: Team namespace allows creating IAM bindings only for their own service accounts and resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) GitOps-managed Pub\/Sub topology<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Pub\/Sub topics\/subscriptions drift across environments.<\/li>\n<li><strong>Why it fits<\/strong>: Declarative manifests ensure consistent topic settings, subscriptions, and IAM.<\/li>\n<li><strong>Example<\/strong>: <code>PubSubTopic<\/code> and <code>PubSubSubscription<\/code> resources deployed per environment namespace.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Standardized service account creation and rotation workflows<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Service accounts are created inconsistently and over-privileged.<\/li>\n<li><strong>Why it fits<\/strong>: Declare service accounts and IAM bindings in code; review via PRs.<\/li>\n<li><strong>Example<\/strong>: Every app namespace declares a dedicated service account plus least-privilege roles.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Environment replication (dev\/test\/prod)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Dev\/test environments differ from prod, causing failures at release time.<\/li>\n<li><strong>Why it fits<\/strong>: Use the same manifests with overlays\/parameters to replicate infra patterns.<\/li>\n<li><strong>Example<\/strong>: Same bucket\/topic resources, different names\/labels and retention settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Central policy enforcement for access and resource management<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams accidentally create insecure resources (public buckets, broad IAM grants).<\/li>\n<li><strong>Why it fits<\/strong>: Pair Config Connector with Kubernetes admission control policies to block noncompliant manifests.<\/li>\n<li><strong>Example<\/strong>: Deny any IAM binding granting <code>roles\/owner<\/code> except to break-glass groups.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Multi-project resource management with namespace-per-project<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Managing many projects manually causes inconsistency and drift.<\/li>\n<li><strong>Why it fits<\/strong>: Each namespace is mapped to a project; teams apply resources within their project boundary.<\/li>\n<li><strong>Example<\/strong>: 50 namespaces correspond to 50 projects, each with standardized logging sinks and buckets (where supported).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Audit-ready infrastructure change management<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Hard to prove who changed IAM or resource policies and when.<\/li>\n<li><strong>Why it fits<\/strong>: Git history + Kubernetes events + Cloud Audit Logs provide a strong audit chain.<\/li>\n<li><strong>Example<\/strong>: PR approval + merge triggers sync; Audit Logs show controller\u2019s API calls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) \u201cDay 2\u201d drift detection and remediation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Someone changes resource settings in Console; configuration drifts from intended state.<\/li>\n<li><strong>Why it fits<\/strong>: Controller reconciliation reverts drift (when allowed by APIs and resource semantics).<\/li>\n<li><strong>Example<\/strong>: A bucket lifecycle policy is removed manually; controller restores it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Platform team templates and golden paths<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams need \u201capproved patterns\u201d for resources, but each team implements differently.<\/li>\n<li><strong>Why it fits<\/strong>: Provide reusable manifests, Kustomize bases, or Helm charts (if your org uses them) that create standardized resources.<\/li>\n<li><strong>Example<\/strong>: Template creates a bucket + service account + IAM binding + labels.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Shared services cluster managing common resources<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Organization wants a single operational hub for shared resource provisioning.<\/li>\n<li><strong>Why it fits<\/strong>: A dedicated cluster runs Config Connector; central team controls access.<\/li>\n<li><strong>Example<\/strong>: Shared cluster manages organization-wide DNS, logging, and core service accounts (verify supported resources and org-level requirements).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Controlled onboarding of new teams\/projects<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: New teams need a consistent set of baseline resources and IAM.<\/li>\n<li><strong>Why it fits<\/strong>: Namespace + baseline manifests can bootstrap approved resources.<\/li>\n<li><strong>Example<\/strong>: Create a namespace, annotate it to a project, apply a baseline bundle.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Feature availability and exact configuration steps can change; verify in official docs for your installed version and GKE release channel.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Kubernetes CRDs for Google Cloud resources<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Exposes Google Cloud resources as Kubernetes API objects (Kinds).<\/li>\n<li><strong>Why it matters<\/strong>: Enables a single, consistent workflow (<code>kubectl<\/code>, GitOps) for cloud resources.<\/li>\n<li><strong>Practical benefit<\/strong>: Infrastructure changes become code-reviewed PRs with consistent patterns.<\/li>\n<li><strong>Caveats<\/strong>: Not all Google Cloud services\/resources are supported; some fields may be immutable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Reconciliation loop (continuous desired-state enforcement)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Continuously reconciles Kubernetes desired state to Google Cloud actual state.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces drift and improves reliability.<\/li>\n<li><strong>Practical benefit<\/strong>: \u201cAccidental console changes\u201d can be automatically corrected.<\/li>\n<li><strong>Caveats<\/strong>: Some changes cannot be forced due to API limitations; expect eventual consistency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Namespaced mode for multi-tenancy<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Enables separation of resources by Kubernetes namespace (often mapping one namespace to one Google Cloud project).<\/li>\n<li><strong>Why it matters<\/strong>: Provides isolation and delegation without granting everyone broad project IAM.<\/li>\n<li><strong>Practical benefit<\/strong>: Platform team can delegate resource management to app teams safely.<\/li>\n<li><strong>Caveats<\/strong>: Cross-project references require careful design; verify supported patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Cluster mode (centralized admin control)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Manages resources cluster-wide (often used by platform admins).<\/li>\n<li><strong>Why it matters<\/strong>: Useful for shared resources or org-wide provisioning.<\/li>\n<li><strong>Practical benefit<\/strong>: Central team manages everything in one place.<\/li>\n<li><strong>Caveats<\/strong>: Higher blast radius; requires stricter RBAC and governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Workload Identity integration (recommended on GKE)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows Kubernetes service accounts to act as Google service accounts without keys.<\/li>\n<li><strong>Why it matters<\/strong>: Avoids long-lived credentials and simplifies rotation.<\/li>\n<li><strong>Practical benefit<\/strong>: Better security posture and reduced secret management overhead.<\/li>\n<li><strong>Caveats<\/strong>: Requires correct IAM bindings and cluster configuration; misconfigurations are a common failure point.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Resource status, conditions, and events<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Writes status back into Kubernetes resources (ready\/not ready, error messages, observed generation).<\/li>\n<li><strong>Why it matters<\/strong>: Makes troubleshooting and automation easier.<\/li>\n<li><strong>Practical benefit<\/strong>: You can <code>kubectl describe<\/code> to find API permission errors, invalid fields, etc.<\/li>\n<li><strong>Caveats<\/strong>: Status messages may be terse; you may need Cloud Audit Logs for deeper detail.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Adoption\/import of existing resources (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows bringing existing Google Cloud resources under Config Connector management.<\/li>\n<li><strong>Why it matters<\/strong>: Enables migration from manual or other IaC approaches.<\/li>\n<li><strong>Practical benefit<\/strong>: Gradual adoption without re-creating everything.<\/li>\n<li><strong>Caveats<\/strong>: Import\/adoption semantics differ by resource; verify official import guidance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Deletion policies \/ lifecycle behavior (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Controls whether deleting the Kubernetes object deletes the Google Cloud resource or \u201cabandons\u201d it.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents accidental destructive operations.<\/li>\n<li><strong>Practical benefit<\/strong>: Safer experimentation and migration.<\/li>\n<li><strong>Caveats<\/strong>: Behavior varies by resource; always test in non-prod first.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Labeling\/annotation patterns for governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Supports labels\/annotations that map to Google Cloud labels and metadata.<\/li>\n<li><strong>Why it matters<\/strong>: Enables cost allocation, ownership tracking, and compliance tagging.<\/li>\n<li><strong>Practical benefit<\/strong>: Standardized labels across resources via templates.<\/li>\n<li><strong>Caveats<\/strong>: Google Cloud label constraints apply (key\/value format and limits).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Compatibility with GitOps and policy-as-code ecosystems<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Works with GitOps sync tools and Kubernetes policy engines.<\/li>\n<li><strong>Why it matters<\/strong>: Enables large-scale governance with automation.<\/li>\n<li><strong>Practical benefit<\/strong>: Prevent noncompliant resources before they are created.<\/li>\n<li><strong>Caveats<\/strong>: Tooling choices vary (Config Sync, Argo CD, Flux, Gatekeeper); integration details are environment-specific.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Config Connector runs controllers inside your Kubernetes cluster. When you apply a manifest for a supported CRD:\n1. Kubernetes stores the object in etcd via the Kubernetes API server.\n2. Config Connector controller watches for new\/changed objects.\n3. The controller authenticates to Google Cloud (commonly via Workload Identity on GKE).\n4. The controller calls the relevant Google Cloud API to create\/update\/delete the resource.\n5. The controller updates Kubernetes status\/conditions and emits events.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane flow<\/strong>: Kubernetes API server \u2192 controller \u2192 Google Cloud APIs<\/li>\n<li><strong>Data plane<\/strong>: Config Connector itself does not typically handle your application data; it manages resource configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM<\/strong>: crucial for controller permissions (roles granted to the Google service account used by Config Connector).<\/li>\n<li><strong>Cloud Resource Manager<\/strong>: project\/folder\/org permissions (depending on what you manage).<\/li>\n<li><strong>Service Usage API<\/strong>: enabling\/disabling Google Cloud services may be required for managed resources.<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: tracks controller API activity (high value for security and compliance).<\/li>\n<li><strong>Cloud Logging\/Monitoring<\/strong>: cluster and controller observability (plus GKE logs\/metrics).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>A Kubernetes cluster<\/strong>, typically <strong>GKE<\/strong>.<\/li>\n<li>Google Cloud APIs for each resource type you manage (for example, <code>storage.googleapis.com<\/code> for buckets).<\/li>\n<li>Identity integration (Workload Identity recommended on GKE).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The controller uses a <strong>Google service account (GSA)<\/strong> identity when calling Google Cloud APIs.<\/li>\n<li>In GKE, best practice is <strong>Workload Identity<\/strong>:<\/li>\n<li>Bind a Kubernetes service account (KSA) used by the controller to a GSA.<\/li>\n<li>Grant the GSA only the permissions required for the resources it manages.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The controller needs outbound access to Google Cloud APIs (public endpoints).<\/li>\n<li>In private cluster environments, ensure NAT or Private Google Access is configured as required (details depend on your network architecture; verify in GKE networking docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor:<\/li>\n<li>controller pod health<\/li>\n<li>reconciliation errors and events<\/li>\n<li>API rate limits<\/li>\n<li>Log:<\/li>\n<li>controller logs in Kubernetes<\/li>\n<li>Cloud Audit Logs in Google Cloud for API activity<\/li>\n<li>Govern:<\/li>\n<li>use namespaces\/RBAC<\/li>\n<li>enforce policy with admission controls<\/li>\n<li>standardize labels and naming<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Engineer \/ CI Pipeline] --&gt;|kubectl apply \/ GitOps sync| K8sAPI[Kubernetes API Server]\n  K8sAPI --&gt; CRD[Config Connector CRDs]\n  K8sAPI --&gt; Ctrl[Config Connector Controller]\n  Ctrl --&gt;|Workload Identity \/ GSA| GCPAPI[Google Cloud APIs]\n  GCPAPI --&gt; Res[Google Cloud Resources\\n(buckets, IAM, Pub\/Sub, ...)]\n  Ctrl --&gt;|status\/conditions| K8sAPI\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  Git[Git Repo: infra manifests] --&gt; CI[CI: validate + policy checks]\n  CI --&gt; Sync[GitOps Sync Tool\\n(e.g., Config Sync \/ Argo CD)]\n  Sync --&gt; K8s[Kubernetes Cluster (GKE)]\n\n  subgraph K8s[Kubernetes Cluster]\n    NS1[Namespace: team-a \/ project-a]\n    NS2[Namespace: team-b \/ project-b]\n    RBAC[Kubernetes RBAC]\n    Policy[Admission Policy\\n(OPA Gatekeeper \/ Policy Controller)]\n    CC[Config Connector Controllers\\n(cnrm-system)]\n  end\n\n  RBAC --&gt; NS1\n  RBAC --&gt; NS2\n  Policy --&gt; K8s\n  NS1 --&gt; CC\n  NS2 --&gt; CC\n\n  CC --&gt;|Workload Identity| GSA[Google Service Account(s)]\n  GSA --&gt; IAM[IAM Roles (least privilege)]\n  CC --&gt; GCP[Google Cloud APIs]\n  GCP --&gt; Projects[Multiple Google Cloud Projects]\n\n  K8s --&gt; Logs[Kubernetes Logs]\n  GCP --&gt; Audit[Cloud Audit Logs]\n  K8s --&gt; Metrics[Cloud Monitoring \/ Prometheus\\n(depending on setup)]\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before you start, ensure you have the following.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud project<\/strong> with <strong>billing enabled<\/strong>.<\/li>\n<li>Permission to create\/manage a GKE cluster and IAM bindings in the project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>Minimum IAM roles vary by what you create. Common needs:\n&#8211; For cluster operations: roles such as <strong>Kubernetes Engine Admin<\/strong> (or a custom equivalent).\n&#8211; For identity setup: ability to create service accounts and IAM bindings.\n&#8211; For resource provisioning: roles corresponding to the resource APIs (for example, Storage Admin for buckets).<\/p>\n\n\n\n<p>Use least privilege and consider custom roles for production. Verify role requirements in official docs for each resource kind.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Config Connector itself does not typically have a separate line-item price, but you pay for:<\/li>\n<li>the Kubernetes cluster (GKE control plane\/management fees depending on mode) and compute<\/li>\n<li>the Google Cloud resources created (buckets, Pub\/Sub, etc.)<\/li>\n<li>logs\/metrics\/storage generated<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>gcloud CLI<\/strong>: https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li><strong>kubectl<\/strong> (often installed via gcloud components)<\/li>\n<li>Optional: <strong>kustomize<\/strong>, <strong>helm<\/strong>, or a GitOps tool (organization-specific)<\/li>\n<li>Access to the <strong>Google Cloud Console<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Depends on <strong>GKE<\/strong> regions and any resource regions you choose.<\/li>\n<li>Config Connector runs in your cluster; choose a region appropriate for your workloads and governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>GKE cluster quotas (nodes, CPU, IPs)<\/li>\n<li>API quotas for the Google Cloud services you manage<\/li>\n<li>Kubernetes API object limits in etcd (large-scale setups require planning)<\/li>\n<li>Controller throughput: many resources can increase reconciliation load<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs<\/h3>\n\n\n\n<p>Commonly required:\n&#8211; Kubernetes Engine API\n&#8211; IAM API\n&#8211; Cloud Resource Manager API\n&#8211; APIs for the resources you plan to manage (Storage API, Pub\/Sub API, etc.)<\/p>\n\n\n\n<p>Verify required APIs per resource type in official docs.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (accurate framing)<\/h3>\n\n\n\n<p>Config Connector is primarily a <strong>controller running in Kubernetes<\/strong>. The cost model is therefore mostly <strong>indirect<\/strong>:\n&#8211; <strong>GKE cost<\/strong> (cluster management fees and compute, depending on Standard vs Autopilot)\n&#8211; <strong>Cost of provisioned Google Cloud resources<\/strong> (Storage, Pub\/Sub, IAM is generally free but managing IAM may generate Audit Logs)\n&#8211; <strong>Networking egress<\/strong> (if applicable)\n&#8211; <strong>Operational telemetry<\/strong> (Logging, Monitoring metrics, log storage)<\/p>\n\n\n\n<p>You should validate current billing details using:\n&#8211; GKE pricing: https:\/\/cloud.google.com\/kubernetes-engine\/pricing<br\/>\n&#8211; Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<br\/>\n&#8211; Pricing for each managed service (for example, Cloud Storage pricing): https:\/\/cloud.google.com\/storage\/pricing<\/p>\n\n\n\n<blockquote>\n<p>If you use <strong>Config Controller<\/strong> (managed control plane), it may have its own pricing model separate from Config Connector. Verify in official docs if you\u2019re evaluating that managed option.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions<\/h3>\n\n\n\n<p>Key dimensions that drive cost:\n1. <strong>Cluster runtime<\/strong>\n   &#8211; Standard GKE: management fee (where applicable) + node VM costs + disks\n   &#8211; Autopilot: pay for requested pod resources + associated overhead (model differs; verify current Autopilot pricing)\n2. <strong>Resource usage<\/strong>\n   &#8211; Storage buckets: storage used, operations, retrieval, network\n   &#8211; Pub\/Sub: message volume, retention, egress\n   &#8211; Databases and compute: instance hours, storage, IOPS, backups\n3. <strong>Logging and audit<\/strong>\n   &#8211; Cloud Audit Logs are generated by Google Cloud API calls; retention\/export can affect cost (verify what\u2019s chargeable in your logging plan)\n4. <strong>Networking<\/strong>\n   &#8211; Controller calls to Google APIs are typically internal\/public API calls; costs are usually dominated by your created resources rather than controller traffic, but egress and NAT can add cost in private networking setups.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>There is no universal \u201cfree tier\u201d specifically for Config Connector, but you might use:\n&#8211; Google Cloud free tier offerings for certain services (varies by product and region; verify)\n&#8211; Small, short-lived GKE clusters to limit cost during labs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Leaving clusters running<\/strong> after tests (common cost leak).<\/li>\n<li><strong>Log volume<\/strong> from frequent reconciliation errors or verbose debugging.<\/li>\n<li><strong>Accidental resource creation<\/strong> (for example, provisioning a database instance) via a manifest merge.<\/li>\n<li><strong>NAT gateway costs<\/strong> (if private cluster needs outbound internet to reach APIs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use short-lived clusters for experiments; automate cleanup.<\/li>\n<li>Use least-privileged provisioning so \u201cexpensive\u201d resources cannot be created by default.<\/li>\n<li>Apply quotas and organization policies (as appropriate) to block certain SKUs.<\/li>\n<li>Reduce log retention or route logs selectively (while preserving security requirements).<\/li>\n<li>Prefer namespaced design with templates that default to low-cost SKUs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (non-numeric guidance)<\/h3>\n\n\n\n<p>A low-cost lab typically includes:\n&#8211; One small GKE cluster (or an existing dev cluster)\n&#8211; A Cloud Storage bucket\n&#8211; A service account and a simple IAM binding<\/p>\n\n\n\n<p>Compute cost will dominate. Use the Pricing Calculator to estimate:\n&#8211; cluster runtime for the expected hours\n&#8211; minimal node pool sizing (Standard) or minimal pod requests (Autopilot)\n&#8211; storage operations (usually small for a lab)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, plan for:\n&#8211; Highly available clusters (multi-zone if required)\n&#8211; GitOps controller overhead, policy engines, and monitoring agents\n&#8211; Larger numbers of managed resources (controller scale and API quota considerations)\n&#8211; Logging and audit retention\/export\n&#8211; Separate clusters\/environments (dev\/stage\/prod) or separate namespaces with strict controls<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab focuses on a realistic, safe, low-cost workflow: <strong>use Config Connector in a GKE cluster to create a Cloud Storage bucket, create a Google service account, and grant it bucket-level access<\/strong>\u2014a common \u201cAccess and resource management\u201d task.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable Config Connector on a GKE cluster.<\/li>\n<li>Configure identity so Config Connector can call Google Cloud APIs securely (Workload Identity recommended).<\/li>\n<li>Provision:<\/li>\n<li>a Cloud Storage bucket<\/li>\n<li>a Google service account<\/li>\n<li>an IAM binding granting that service account access to the bucket<\/li>\n<li>Validate results in both Kubernetes and Google Cloud.<\/li>\n<li>Clean up everything to avoid ongoing cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create or select a Google Cloud project and enable required APIs.\n2. Create a GKE cluster with Workload Identity enabled.\n3. Enable Config Connector on the cluster (GKE add-on) and verify controller pods.\n4. Create a Google service account for Config Connector operations and bind it to the controller\u2019s Kubernetes service account (Workload Identity binding).\n5. Configure a namespace-to-project mapping (namespaced mode) and apply Config Connector custom resources.\n6. Apply manifests to create a bucket, service account, and bucket IAM membership.\n7. Validate and troubleshoot.\n8. Clean up.<\/p>\n\n\n\n<blockquote>\n<p>Important: Exact console labels and some resource kind names can change. Where this tutorial references a specific CRD kind or annotation, <strong>verify in the official Config Connector resource reference<\/strong> for your version:\nhttps:\/\/cloud.google.com\/config-connector\/docs\/reference\/overview<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set environment variables and select your project<\/h3>\n\n\n\n<p>1) Authenticate and select a project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth login\ngcloud config set project YOUR_PROJECT_ID\ngcloud config set compute\/region us-central1\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: <code>gcloud config get-value project<\/code> prints your project.<\/p>\n\n\n\n<p>2) Enable required APIs (common set; add more as needed):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  container.googleapis.com \\\n  iam.googleapis.com \\\n  cloudresourcemanager.googleapis.com \\\n  storage.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: APIs are enabled without errors.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a GKE cluster with Workload Identity enabled<\/h3>\n\n\n\n<p>You can use an existing cluster, but for a clean lab, create a dedicated one. Cluster sizing and mode affect cost\u2014delete it afterward.<\/p>\n\n\n\n<p>Create a Standard cluster (example; adjust region\/zone and sizing):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"$(gcloud config get-value project)\"\nexport REGION=\"us-central1\"\nexport CLUSTER_NAME=\"cc-lab\"\n\ngcloud container clusters create \"$CLUSTER_NAME\" \\\n  --region \"$REGION\" \\\n  --workload-pool=\"${PROJECT_ID}.svc.id.goog\" \\\n  --num-nodes 1\n<\/code><\/pre>\n\n\n\n<p>Get credentials:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters get-credentials \"$CLUSTER_NAME\" --region \"$REGION\"\nkubectl cluster-info\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: <code>kubectl<\/code> connects to the cluster.<\/p>\n\n\n\n<blockquote>\n<p>If you prefer Autopilot or private clusters, follow official GKE guidance and ensure outbound access to Google APIs. Autopilot and add-on availability can vary\u2014verify in GKE docs.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Enable Config Connector and verify it is running<\/h3>\n\n\n\n<p><strong>Preferred (GKE add-on):<\/strong> Enable Config Connector in the Google Cloud Console for the cluster.<\/p>\n\n\n\n<p>General console path (may vary):\n&#8211; Google Cloud Console \u2192 <strong>Kubernetes Engine<\/strong> \u2192 <strong>Clusters<\/strong>\n&#8211; Select your cluster \u2192 <strong>Features<\/strong> \/ <strong>Add-ons<\/strong>\n&#8211; Enable <strong>Config Connector<\/strong>\n&#8211; Apply changes and wait for rollout<\/p>\n\n\n\n<p><strong>Verification (in Kubernetes):<\/strong><\/p>\n\n\n\n<p>Check for the Config Connector system namespace and pods. Common namespace is <code>cnrm-system<\/code> (verify in your cluster):<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get namespaces\nkubectl get pods -A | grep -E \"cnrm|config|connector\" || true\n<\/code><\/pre>\n\n\n\n<p>If you see <code>cnrm-system<\/code>, inspect pods:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get pods -n cnrm-system\nkubectl logs -n cnrm-system deploy\/cnrm-controller-manager --tail=100\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Controller pods are Running\/Ready, logs show normal startup (no repeated auth failures).<\/p>\n\n\n\n<blockquote>\n<p>If the add-on is not available in your cluster version\/channel, follow the official installation guide:\nhttps:\/\/cloud.google.com\/config-connector\/docs\/how-to\/install-upgrade-uninstall<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Configure identity (Workload Identity binding)<\/h3>\n\n\n\n<p>Config Connector needs Google Cloud permissions. A common and recommended approach on GKE is:\n&#8211; Create a <strong>Google service account (GSA)<\/strong> that will represent Config Connector\u2019s Google Cloud identity.\n&#8211; Bind the controller\u2019s <strong>Kubernetes service account (KSA)<\/strong> to that GSA using Workload Identity.\n&#8211; Grant the GSA only the roles required for this lab.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">4.1 Identify the controller\u2019s Kubernetes service account<\/h4>\n\n\n\n<p>List service accounts in <code>cnrm-system<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get serviceaccounts -n cnrm-system\n<\/code><\/pre>\n\n\n\n<p>A commonly used KSA name is <code>cnrm-controller-manager<\/code> (verify in your cluster output). Export variables:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export KSA_NAMESPACE=\"cnrm-system\"\nexport KSA_NAME=\"cnrm-controller-manager\"\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">4.2 Create a Google service account for Config Connector<\/h4>\n\n\n\n<pre><code class=\"language-bash\">export CC_GSA_NAME=\"config-connector-lab\"\nexport CC_GSA_EMAIL=\"${CC_GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com\"\n\ngcloud iam service-accounts create \"$CC_GSA_NAME\" \\\n  --display-name \"Config Connector Lab Service Account\"\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">4.3 Grant least-privilege roles for this lab<\/h4>\n\n\n\n<p>For this lab we need:\n&#8211; Create\/manage Cloud Storage bucket and IAM on that bucket\n&#8211; Create IAM service account resources<\/p>\n\n\n\n<p>Typical roles (verify exact required roles in your environment):\n&#8211; <code>roles\/storage.admin<\/code> (buckets + IAM bindings)\n&#8211; <code>roles\/iam.serviceAccountAdmin<\/code> (create service accounts)<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects add-iam-policy-binding \"$PROJECT_ID\" \\\n  --member=\"serviceAccount:${CC_GSA_EMAIL}\" \\\n  --role=\"roles\/storage.admin\"\n\ngcloud projects add-iam-policy-binding \"$PROJECT_ID\" \\\n  --member=\"serviceAccount:${CC_GSA_EMAIL}\" \\\n  --role=\"roles\/iam.serviceAccountAdmin\"\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">4.4 Bind the Kubernetes service account to the Google service account<\/h4>\n\n\n\n<pre><code class=\"language-bash\">gcloud iam service-accounts add-iam-policy-binding \"$CC_GSA_EMAIL\" \\\n  --member=\"serviceAccount:${PROJECT_ID}.svc.id.goog[${KSA_NAMESPACE}\/${KSA_NAME}]\" \\\n  --role=\"roles\/iam.workloadIdentityUser\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: IAM bindings succeed without permission errors.<\/p>\n\n\n\n<blockquote>\n<p>Common error: <code>PERMISSION_DENIED<\/code> when adding IAM bindings. Ensure your user has permission to set IAM policy (for example, Project IAM Admin) or use an authorized admin account.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Configure namespaced management (project mapping)<\/h3>\n\n\n\n<p>In many setups, you map a Kubernetes namespace to a Google Cloud project for namespaced mode. The exact method can be:\n&#8211; a namespace annotation (common), and\/or\n&#8211; a <code>ConfigConnectorContext<\/code> custom resource (depending on mode\/version)<\/p>\n\n\n\n<p>Because these details can vary by version, <strong>verify the current recommended approach<\/strong>:\n&#8211; Namespaced mode overview: https:\/\/cloud.google.com\/config-connector\/docs\/concepts\/namespace-management<\/p>\n\n\n\n<p>Create a namespace for this lab:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export NS=\"cc-demo\"\nkubectl create namespace \"$NS\"\n<\/code><\/pre>\n\n\n\n<p>Annotate the namespace with the project ID (commonly supported pattern):<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl annotate namespace \"$NS\" cnrm.cloud.google.com\/project-id=\"$PROJECT_ID\" --overwrite\n<\/code><\/pre>\n\n\n\n<p>If your version requires associating the GSA at the namespace level, consult the namespaced mode docs and apply the recommended annotation or <code>ConfigConnectorContext<\/code>.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: Namespace exists and has the correct annotation:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get namespace \"$NS\" -o jsonpath='{.metadata.annotations.cnrm\\.cloud\\.google\\.com\/project-id}{\"\\n\"}'\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Apply Config Connector resources (bucket, service account, IAM)<\/h3>\n\n\n\n<p>Now you will apply three resources:\n1. A Cloud Storage bucket\n2. A Google service account\n3. A bucket-level IAM binding granting the service account access<\/p>\n\n\n\n<blockquote>\n<p>Resource kinds and fields must match the Config Connector resource reference for your installed version. Verify the exact Kind names and API groups here:\nhttps:\/\/cloud.google.com\/config-connector\/docs\/reference\/overview<\/p>\n<\/blockquote>\n\n\n\n<p>Create a working directory:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p cc-lab &amp;&amp; cd cc-lab\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">6.1 Create a Storage bucket resource manifest<\/h4>\n\n\n\n<p>Create <code>bucket.yaml<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-yaml\">apiVersion: storage.cnrm.cloud.google.com\/v1beta1\nkind: StorageBucket\nmetadata:\n  name: cc-lab-bucket-unique-12345\n  namespace: cc-demo\nspec:\n  location: US\n  uniformBucketLevelAccess: true\n<\/code><\/pre>\n\n\n\n<p>Apply it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl apply -f bucket.yaml\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Kubernetes accepts the object. The bucket will become Ready after reconciliation.<\/p>\n\n\n\n<p>Check status:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get storagebucket -n \"$NS\"\nkubectl describe storagebucket -n \"$NS\" cc-lab-bucket-unique-12345\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>Bucket names must be globally unique. Change <code>cc-lab-bucket-unique-12345<\/code> to something unique (for example, include your project ID or random suffix).<\/p>\n<\/blockquote>\n\n\n\n<h4 class=\"wp-block-heading\">6.2 Create a Google service account manifest<\/h4>\n\n\n\n<p>Create <code>app-sa.yaml<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-yaml\">apiVersion: iam.cnrm.cloud.google.com\/v1beta1\nkind: IAMServiceAccount\nmetadata:\n  name: cc-app-sa\n  namespace: cc-demo\nspec:\n  displayName: \"Config Connector App Service Account\"\n<\/code><\/pre>\n\n\n\n<p>Apply:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl apply -f app-sa.yaml\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: A Google service account is created in the project.<\/p>\n\n\n\n<p>Verify in Kubernetes:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get iamserviceaccount -n \"$NS\"\nkubectl describe iamserviceaccount -n \"$NS\" cc-app-sa\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">6.3 Grant the service account access to the bucket (IAM binding)<\/h4>\n\n\n\n<p>Depending on the resource reference, the Kind may be <code>StorageBucketIAMMember<\/code> or similar. <strong>Verify the correct Kind and fields<\/strong> in the official resource reference for Cloud Storage IAM resources.<\/p>\n\n\n\n<p>Example manifest <code>bucket-iam.yaml<\/code> (verify Kind\/fields):<\/p>\n\n\n\n<pre><code class=\"language-yaml\">apiVersion: storage.cnrm.cloud.google.com\/v1beta1\nkind: StorageBucketIAMMember\nmetadata:\n  name: cc-app-sa-objectadmin\n  namespace: cc-demo\nspec:\n  bucketRef:\n    name: cc-lab-bucket-unique-12345\n  role: roles\/storage.objectAdmin\n  member: serviceAccount:cc-app-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com\n<\/code><\/pre>\n\n\n\n<p>Before applying, replace <code>YOUR_PROJECT_ID<\/code> with your project ID:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sed -i.bak \"s\/YOUR_PROJECT_ID\/${PROJECT_ID}\/g\" bucket-iam.yaml\nkubectl apply -f bucket-iam.yaml\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The IAM membership resource becomes Ready, and the service account gains the role on the bucket.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Validate in Kubernetes<\/h4>\n\n\n\n<p>Check readiness and conditions:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get storagebucket,iamserviceaccount -n \"$NS\"\nkubectl get storagebucketiammember -n \"$NS\" || true\n<\/code><\/pre>\n\n\n\n<p>Describe resources to check conditions:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl describe storagebucket -n \"$NS\" cc-lab-bucket-unique-12345\nkubectl describe iamserviceaccount -n \"$NS\" cc-app-sa\nkubectl describe storagebucketiammember -n \"$NS\" cc-app-sa-objectadmin || true\n<\/code><\/pre>\n\n\n\n<p>Look for:\n&#8211; <code>Ready=True<\/code>\n&#8211; no repeated reconciliation errors\n&#8211; status fields populated (depends on resource kind)<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Validate in Google Cloud<\/h4>\n\n\n\n<p>Verify the bucket exists:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud storage buckets list --filter=\"name:cc-lab-bucket\"\n<\/code><\/pre>\n\n\n\n<p>Verify the service account exists:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud iam service-accounts list --filter=\"email:cc-app-sa@${PROJECT_ID}.iam.gserviceaccount.com\"\n<\/code><\/pre>\n\n\n\n<p>Check bucket IAM policy includes the service account (may require additional permissions to view IAM):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud storage buckets get-iam-policy gs:\/\/cc-lab-bucket-unique-12345\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<p>1) <strong>CRD not found \/ \u201cno matches for kind \u2026\u201d<\/strong>\n&#8211; Cause: Config Connector not installed or not fully initialized.\n&#8211; Fix:\n  &#8211; Confirm add-on is enabled.\n  &#8211; Check CRDs: <code>kubectl get crds | grep cnrm<\/code>\n  &#8211; Follow official install steps: https:\/\/cloud.google.com\/config-connector\/docs\/how-to\/install-upgrade-uninstall<\/p>\n\n\n\n<p>2) <strong>Permission denied errors in resource status<\/strong>\n&#8211; Cause: The GSA used by Config Connector lacks required IAM roles, or Workload Identity binding is wrong.\n&#8211; Fix:\n  &#8211; Check controller logs:<br\/>\n<code>kubectl logs -n cnrm-system deploy\/cnrm-controller-manager --tail=200<\/code>\n  &#8211; Confirm Workload Identity binding is correct:\n    &#8211; correct project workload pool\n    &#8211; correct KSA name\/namespace\n  &#8211; Grant the minimal additional role required (based on error), then re-check.<\/p>\n\n\n\n<p>3) <strong>Bucket name conflict<\/strong>\n&#8211; Cause: Bucket names are globally unique.\n&#8211; Fix: Change the manifest <code>metadata.name<\/code> to a unique value, delete\/reapply if needed.<\/p>\n\n\n\n<p>4) <strong>Resource stuck in NotReady<\/strong>\n&#8211; Cause: API not enabled, invalid field, organization policy constraints, or quota issues.\n&#8211; Fix:\n  &#8211; Check <code>kubectl describe<\/code> conditions\/events.\n  &#8211; Check Cloud Audit Logs for the failed API call and reason (recommended for deep debugging).\n  &#8211; Verify required APIs are enabled.<\/p>\n\n\n\n<p>5) <strong>IAM binding resource kind mismatch<\/strong>\n&#8211; Cause: The exact IAM CRD kind for Cloud Storage may differ by version.\n&#8211; Fix: Use the official reference and adjust the Kind\/fields accordingly:\n  https:\/\/cloud.google.com\/config-connector\/docs\/reference\/overview<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Delete Kubernetes resources (this removes or updates Google Cloud resources depending on deletion behavior and resource type):<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl delete -n \"$NS\" -f bucket-iam.yaml || true\nkubectl delete -n \"$NS\" -f app-sa.yaml || true\nkubectl delete -n \"$NS\" -f bucket.yaml || true\nkubectl delete namespace \"$NS\"\n<\/code><\/pre>\n\n\n\n<p>Delete the cluster (major cost saver):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters delete \"$CLUSTER_NAME\" --region \"$REGION\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Delete the Config Connector Google service account used for reconciliation:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud iam service-accounts delete \"$CC_GSA_EMAIL\" --quiet\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: No cluster remains, and the lab service accounts\/resources are removed.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Namespace-per-project<\/strong> is a common, scalable pattern:<\/li>\n<li>one namespace maps to one Google Cloud project<\/li>\n<li>enforce boundaries with RBAC and policy<\/li>\n<li>Use a <strong>dedicated infrastructure management cluster<\/strong> or dedicated namespaces with strict controls for production.<\/li>\n<li>Design for <strong>bootstrap<\/strong>:<\/li>\n<li>you may still need Terraform\/gcloud to create the first cluster and initial IAM bindings<\/li>\n<li>then hand off ongoing resource management to Config Connector<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Workload Identity<\/strong> instead of service account keys.<\/li>\n<li>Grant the Config Connector GSA <strong>least privilege<\/strong>:<\/li>\n<li>avoid broad roles like Owner\/Editor in production<\/li>\n<li>use custom roles where appropriate<\/li>\n<li>Use separate GSAs for different environments or namespaces if your design supports it (verify supported patterns).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Auto-delete dev clusters<\/strong> and use short-lived environments.<\/li>\n<li>Prevent expensive resources via:<\/li>\n<li>policy-as-code (deny certain Kinds)<\/li>\n<li>organization policies and quotas<\/li>\n<li>Manage log volume:<\/li>\n<li>investigate repeated reconciliation failures quickly<\/li>\n<li>right-size log retention and sinks based on compliance needs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid \u201cone cluster managing everything at org scale\u201d unless you\u2019ve planned:<\/li>\n<li>API quotas<\/li>\n<li>controller scaling<\/li>\n<li>etcd object growth and watch pressure<\/li>\n<li>Batch changes via GitOps PRs and avoid constant churn.<\/li>\n<li>Use stable naming conventions to reduce accidental deletes\/recreates.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat the cluster as critical infrastructure:<\/li>\n<li>monitor controller health and reconciliation error rates<\/li>\n<li>protect the cluster with strong access controls<\/li>\n<li>Use staging environments to test manifest changes before production.<\/li>\n<li>Understand immutable fields: some changes require replacement, which can be destructive.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize:<\/li>\n<li>labels (<code>env<\/code>, <code>team<\/code>, <code>cost-center<\/code>, <code>owner<\/code>)<\/li>\n<li>naming conventions (resource and namespace)<\/li>\n<li>Create runbooks:<\/li>\n<li>reconciliation failures<\/li>\n<li>permission denied<\/li>\n<li>quota and org-policy violations<\/li>\n<li>Use Cloud Audit Logs to trace \u201cwho did what\u201d for API calls (controller identity).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce labels via admission policies.<\/li>\n<li>Require a consistent naming scheme (for example, <code>${team}-${env}-${purpose}<\/code>).<\/li>\n<li>Document which team \u201cowns\u201d each namespace\/project mapping.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Config Connector controllers act with the permissions of a <strong>Google service account<\/strong> (directly or via Workload Identity).<\/li>\n<li>Kubernetes users\u2019 ability to create\/update resources is controlled by <strong>Kubernetes RBAC<\/strong>.<\/li>\n<li>Secure design requires both layers:<\/li>\n<li>Kubernetes RBAC limits who can submit manifests<\/li>\n<li>Google Cloud IAM limits what the controller can do even if a manifest is applied<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud resources are encrypted at rest by default for many services (service-specific; verify).<\/li>\n<li>Kubernetes secrets and etcd encryption depend on cluster configuration (GKE features vary; verify).<\/li>\n<li>Prefer not to store sensitive values in plain manifests. Use secret management patterns appropriate for your org.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Controller needs access to Google APIs.<\/li>\n<li>In private clusters, ensure correct outbound routing\/NAT\/Private Google Access as needed.<\/li>\n<li>Restrict cluster API access (authorized networks, private endpoint) per your security baseline.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>Workload Identity<\/strong> so you don\u2019t store service account keys.<\/li>\n<li>If any workflow uses keys (legacy), treat them as high-risk:<\/li>\n<li>rotate frequently<\/li>\n<li>store in Secret Manager<\/li>\n<li>scope permissions narrowly<\/li>\n<li>migrate to Workload Identity where possible<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Cloud Audit Logs<\/strong> to monitor:<\/li>\n<li>IAM policy changes<\/li>\n<li>service account creation<\/li>\n<li>storage IAM changes<\/li>\n<li>Correlate Kubernetes events (who applied which manifest) with Audit Logs (what API calls occurred).<\/li>\n<li>Consider exporting relevant logs to a SIEM (organization-specific).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Maintain separation of duties:<\/li>\n<li>platform admins manage controller permissions and policies<\/li>\n<li>teams manage resources within approved boundaries<\/li>\n<li>Use policy-as-code to enforce compliance guardrails before resources are created.<\/li>\n<li>Review data residency requirements for resources (bucket location\/region).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Granting the controller\u2019s GSA broad roles like <code>roles\/owner<\/code>.<\/li>\n<li>Allowing many users cluster-admin rights, enabling them to create arbitrary infrastructure resources.<\/li>\n<li>Not restricting which namespaces can manage which projects\/resources.<\/li>\n<li>Storing secrets in Git without encryption or access controls.<\/li>\n<li>Ignoring Audit Logs and controller reconciliation errors.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Workload Identity.<\/li>\n<li>Use namespaced mode with strict RBAC.<\/li>\n<li>Enforce admission policies (deny risky resource configs).<\/li>\n<li>Maintain separate environments and promotion pipelines.<\/li>\n<li>Monitor and alert on IAM-related changes initiated by the controller identity.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Config Connector is powerful, but it is not \u201cmagic Terraform in Kubernetes.\u201d Plan for these realities:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Resource coverage is not universal<\/strong>: Not every Google Cloud resource has a CRD. Always verify in the official resource reference.<\/li>\n<li><strong>Immutable fields<\/strong>: Many resources have fields that force replacement. Replacement can mean downtime or data loss (for example, deleting and recreating).<\/li>\n<li><strong>Eventual consistency<\/strong>: Some APIs take time; reconciliation may show intermediate states.<\/li>\n<li><strong>API quotas and rate limits<\/strong>: Large-scale reconciliations can hit API limits.<\/li>\n<li><strong>Multi-project complexity<\/strong>: Mapping namespaces to projects is straightforward; cross-project dependencies and shared resources require careful design.<\/li>\n<li><strong>Bootstrap problem<\/strong>: You often need to create the first cluster and IAM bindings using other tools before Config Connector can manage things.<\/li>\n<li><strong>Operational dependency on the cluster<\/strong>: If the cluster is down, reconciliation stops (resources remain in Google Cloud, but drift won\u2019t be corrected).<\/li>\n<li><strong>Deletion behavior surprises<\/strong>: Deleting a Kubernetes object can delete the real Google Cloud resource unless configured otherwise (verify deletion policy support).<\/li>\n<li><strong>UI\/feature availability varies by GKE version\/channel<\/strong>: Add-ons and supported versions change; verify with current GKE and Config Connector docs.<\/li>\n<li><strong>Troubleshooting often requires two planes<\/strong>:<\/li>\n<li>Kubernetes status\/events\/logs<\/li>\n<li>Cloud Audit Logs for API call failures<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Config Connector is one option in the Google Cloud infrastructure management toolbox. Here\u2019s how it compares.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Config Connector (Google Cloud)<\/strong><\/td>\n<td>Kubernetes-centric orgs managing Google Cloud resources declaratively<\/td>\n<td>Kubernetes-native workflow, reconciliation, GitOps-friendly, integrates with RBAC\/namespaces<\/td>\n<td>Requires Kubernetes operational maturity; not all resources supported<\/td>\n<td>You run GKE\/Kubernetes and want Kubernetes as the control plane for Google Cloud resources<\/td>\n<\/tr>\n<tr>\n<td><strong>Config Controller (Google Cloud)<\/strong><\/td>\n<td>Managed control plane approach (hosted)<\/td>\n<td>Reduces need to operate your own cluster for infra management<\/td>\n<td>Separate product with its own constraints\/cost; verify resource coverage and pricing<\/td>\n<td>You want managed operations while keeping Config Connector-style workflows<\/td>\n<\/tr>\n<tr>\n<td><strong>Terraform (HashiCorp)<\/strong><\/td>\n<td>Broad IaC across clouds and services<\/td>\n<td>Mature ecosystem, wide provider coverage, strong plan\/apply workflow<\/td>\n<td>Not Kubernetes-native; state management overhead<\/td>\n<td>You need broad coverage, multi-cloud, or provisioning before Kubernetes exists<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud CLI \/ Console<\/strong><\/td>\n<td>Ad-hoc operations, small setups<\/td>\n<td>Direct, quick, no controller<\/td>\n<td>Not declarative; drift and auditability issues; hard to scale<\/td>\n<td>Small teams, emergency ops, or one-off changes<\/td>\n<\/tr>\n<tr>\n<td><strong>Pulumi<\/strong><\/td>\n<td>IaC with general-purpose languages<\/td>\n<td>Strong developer experience, testing<\/td>\n<td>Still needs state; not Kubernetes-native<\/td>\n<td>Teams prefer code-based IaC and want strong software engineering patterns<\/td>\n<\/tr>\n<tr>\n<td><strong>Crossplane (open source)<\/strong><\/td>\n<td>Kubernetes-native IaC across clouds<\/td>\n<td>Kubernetes API approach like Config Connector; multi-cloud<\/td>\n<td>Additional control plane complexity; provider maturity varies<\/td>\n<td>You want Kubernetes-native multi-cloud infrastructure patterns<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS CloudFormation \/ Azure ARM\/Bicep<\/strong><\/td>\n<td>Native IaC in other clouds<\/td>\n<td>Deep integration in their ecosystems<\/td>\n<td>Not applicable to Google Cloud directly<\/td>\n<td>Choose when you are operating primarily in those clouds<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (multi-team, governed access\/resource management)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A large enterprise has dozens of Google Cloud projects and teams. IAM requests and resource provisioning (buckets, Pub\/Sub, service accounts) are bottlenecked. Auditors require traceability for IAM changes.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>A dedicated GKE \u201cplatform control\u201d cluster runs Config Connector.<\/li>\n<li>Namespaces map to projects: <code>team-a-prod<\/code>, <code>team-b-prod<\/code>, etc.<\/li>\n<li>Kubernetes RBAC restricts teams to their namespaces.<\/li>\n<li>Admission policies enforce guardrails (no public buckets, restricted IAM roles).<\/li>\n<li>GitOps sync deploys approved manifests from a central repo.<\/li>\n<li>Cloud Audit Logs are monitored and exported to a SIEM.<\/li>\n<li><strong>Why Config Connector was chosen<\/strong>:<\/li>\n<li>The org already standardizes on Kubernetes workflows and GitOps.<\/li>\n<li>Namespaced delegation aligns with team\/project boundaries.<\/li>\n<li>Auditability is improved: PR history + Kubernetes events + Cloud Audit Logs.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster, safer provisioning with self-service patterns.<\/li>\n<li>Fewer IAM misconfigurations due to policy enforcement.<\/li>\n<li>Stronger audit evidence for access changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (simple, pragmatic)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A startup runs GKE and wants to manage a small set of cloud resources (buckets, Pub\/Sub, service accounts) alongside app deployments, with minimal tool sprawl.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>A single GKE cluster (dev\/prod split by namespaces or separate clusters depending on maturity).<\/li>\n<li>Config Connector enabled; one namespace per environment.<\/li>\n<li>Minimal policy: enforce naming and block obviously risky configs.<\/li>\n<li>CI pipeline applies manifests after code review.<\/li>\n<li><strong>Why Config Connector was chosen<\/strong>:<\/li>\n<li>Team already uses Kubernetes daily.<\/li>\n<li>Reduces need to manage Terraform state and separate pipelines early on.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster onboarding and consistent resource creation.<\/li>\n<li>Easy cleanup of dev resources by deleting namespace objects (with careful deletion policies).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Config Connector a Google Cloud API service or a Kubernetes controller?<\/strong><br\/>\nIt\u2019s primarily a <strong>Kubernetes controller + CRDs<\/strong> that manages Google Cloud resources by calling Google Cloud APIs.<\/p>\n\n\n\n<p>2) <strong>Does Config Connector replace Terraform?<\/strong><br\/>\nNot universally. It\u2019s best when you want <strong>Kubernetes-native infrastructure management<\/strong>. Terraform still excels for broad coverage, multi-cloud, and provisioning before Kubernetes exists.<\/p>\n\n\n\n<p>3) <strong>What\u2019s the difference between Config Connector and Config Controller?<\/strong><br\/>\nConfig Connector is the controller\/CRDs. Config Controller is a <strong>managed<\/strong> Google Cloud offering that provides a hosted control plane for similar workflows. Verify current product positioning in official docs.<\/p>\n\n\n\n<p>4) <strong>Can I use Config Connector without GKE?<\/strong><br\/>\nIt runs on Kubernetes. GKE is the most common supported environment in Google Cloud docs. For non-GKE Kubernetes, supportability and setup may differ\u2014verify official documentation for your environment.<\/p>\n\n\n\n<p>5) <strong>Is Workload Identity required?<\/strong><br\/>\nNot always, but it is commonly the <strong>recommended<\/strong> authentication method on GKE because it avoids long-lived keys. Verify supported auth methods for your installation mode.<\/p>\n\n\n\n<p>6) <strong>How do I prevent teams from creating expensive resources?<\/strong><br\/>\nUse a combination of:\n&#8211; Kubernetes RBAC (who can apply which kinds)\n&#8211; Admission policies (deny certain resources\/fields)\n&#8211; Google Cloud organization policies and quotas<\/p>\n\n\n\n<p>7) <strong>What happens if someone changes a resource in the Console?<\/strong><br\/>\nConfig Connector reconciliation may revert the change if the field is managed and mutable. Some fields may not be enforced due to API constraints. Always test.<\/p>\n\n\n\n<p>8) <strong>Can Config Connector manage IAM policies safely?<\/strong><br\/>\nYes, but IAM is high-risk. Use least privilege, strong review processes, and consider partial-policy patterns where supported. Verify IAM CRD semantics carefully.<\/p>\n\n\n\n<p>9) <strong>How do I troubleshoot a NotReady resource?<\/strong><br\/>\nStart with:\n&#8211; <code>kubectl describe<\/code> (conditions\/events)\n&#8211; controller logs\nThen check <strong>Cloud Audit Logs<\/strong> for API errors (permission denied, invalid argument, org policy).<\/p>\n\n\n\n<p>10) <strong>Does deleting the Kubernetes object delete the Google Cloud resource?<\/strong><br\/>\nOften yes, unless configured otherwise and supported by that resource. Verify deletion policy behavior per resource kind.<\/p>\n\n\n\n<p>11) <strong>How do I manage multiple projects?<\/strong><br\/>\nA common pattern is <strong>namespace-per-project<\/strong>, with each namespace mapped to a project via annotations or context resources (depending on version).<\/p>\n\n\n\n<p>12) <strong>Can Config Connector create projects and folders?<\/strong><br\/>\nSome resource hierarchy objects may be supported, but this is advanced and permission-heavy. Verify official resource coverage and constraints.<\/p>\n\n\n\n<p>13) <strong>Is Config Connector suitable for production?<\/strong><br\/>\nYes, with proper operations: stable clusters, strong RBAC, policy enforcement, monitoring, and tested release processes.<\/p>\n\n\n\n<p>14) <strong>What\u2019s the biggest operational risk?<\/strong><br\/>\nTreating the cluster as \u201cjust another cluster.\u201d If it\u2019s your infrastructure control plane, it needs production-grade operations and access controls.<\/p>\n\n\n\n<p>15) <strong>How do I keep manifests compatible over time?<\/strong><br\/>\nPin versions where applicable, follow release notes, test changes in staging, and regularly verify CRD\/apiVersion changes in official docs.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Config Connector<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Config Connector overview \u2013 https:\/\/cloud.google.com\/config-connector\/docs\/overview<\/td>\n<td>Core concepts, installation paths, and supported patterns<\/td>\n<\/tr>\n<tr>\n<td>Official reference<\/td>\n<td>Resource reference overview \u2013 https:\/\/cloud.google.com\/config-connector\/docs\/reference\/overview<\/td>\n<td>Authoritative list of supported resource kinds, fields, and examples<\/td>\n<\/tr>\n<tr>\n<td>Official guide<\/td>\n<td>Install\/upgrade\/uninstall \u2013 https:\/\/cloud.google.com\/config-connector\/docs\/how-to\/install-upgrade-uninstall<\/td>\n<td>Current installation workflow and operational tasks<\/td>\n<\/tr>\n<tr>\n<td>Official concept docs<\/td>\n<td>Namespace management \u2013 https:\/\/cloud.google.com\/config-connector\/docs\/concepts\/namespace-management<\/td>\n<td>Namespaced vs cluster mode and multi-tenancy patterns<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>GKE pricing \u2013 https:\/\/cloud.google.com\/kubernetes-engine\/pricing<\/td>\n<td>Primary indirect cost driver when running Config Connector on GKE<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator \u2013 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Model cluster and resource costs without guessing numbers<\/td>\n<\/tr>\n<tr>\n<td>Product docs<\/td>\n<td>Workload Identity (GKE) \u2013 https:\/\/cloud.google.com\/kubernetes-engine\/docs\/concepts\/workload-identity<\/td>\n<td>Secure authentication model used by Config Connector in many deployments<\/td>\n<\/tr>\n<tr>\n<td>Observability<\/td>\n<td>Cloud Audit Logs \u2013 https:\/\/cloud.google.com\/logging\/docs\/audit<\/td>\n<td>Essential for tracking API calls and troubleshooting permission issues<\/td>\n<\/tr>\n<tr>\n<td>Architecture<\/td>\n<td>Google Cloud Architecture Center \u2013 https:\/\/cloud.google.com\/architecture<\/td>\n<td>Patterns for landing zones, governance, and platform engineering (search within for relevant guides)<\/td>\n<\/tr>\n<tr>\n<td>Source\/examples<\/td>\n<td>Config Connector samples (verify official GitHub links from docs)<\/td>\n<td>Practical manifests and patterns; always prefer links from official docs to avoid outdated samples<\/td>\n<\/tr>\n<tr>\n<td>Video<\/td>\n<td>Google Cloud Tech \/ official YouTube channels (search \u201cConfig Connector\u201d)<\/td>\n<td>Visual walkthroughs; verify recency and version alignment<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>Kubernetes + DevOps practices; may include IaC and cloud governance concepts<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Students and early-career engineers<\/td>\n<td>DevOps foundations, SCM, CI\/CD<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud\/DevOps practitioners<\/td>\n<td>Cloud operations, automation, operational readiness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs and operations teams<\/td>\n<td>Reliability engineering, observability, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>Monitoring\/automation\/AIOps concepts<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud coaching content (verify offerings)<\/td>\n<td>Engineers looking for guided learning<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training programs (verify catalog)<\/td>\n<td>Individuals and teams<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps services\/training (verify offerings)<\/td>\n<td>Startups and small teams<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resources (verify offerings)<\/td>\n<td>Operations teams needing practical support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service lines)<\/td>\n<td>Platform engineering, Kubernetes operations, DevOps pipelines<\/td>\n<td>GKE platform setup, GitOps rollout, governance guardrails<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training (verify offerings)<\/td>\n<td>DevOps transformation, Kubernetes enablement<\/td>\n<td>Config Connector adoption plan, CI\/CD + policy-as-code implementation<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify offerings)<\/td>\n<td>Automation, cloud operations, toolchain integration<\/td>\n<td>Infrastructure automation, operational readiness reviews, cost optimization<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Config Connector<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud fundamentals:<\/li>\n<li>projects, IAM, service accounts<\/li>\n<li>resource hierarchy concepts<\/li>\n<li>billing and quotas<\/li>\n<li>Kubernetes fundamentals:<\/li>\n<li>namespaces, RBAC, service accounts<\/li>\n<li>controllers and reconciliation model<\/li>\n<li><code>kubectl<\/code>, manifests, and basic troubleshooting<\/li>\n<li>GKE basics:<\/li>\n<li>cluster creation, node pools, networking basics<\/li>\n<li>Workload Identity concepts<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Config Connector<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>GitOps operations:<\/li>\n<li>PR-based deployment workflows<\/li>\n<li>environment promotion strategies<\/li>\n<li>Policy as code:<\/li>\n<li>admission control patterns<\/li>\n<li>guardrails for IAM and resource configuration<\/li>\n<li>Advanced Google Cloud governance:<\/li>\n<li>organization policies<\/li>\n<li>audit log exports and SIEM integrations<\/li>\n<li>labeling and cost allocation<\/li>\n<li>Scaling platform engineering:<\/li>\n<li>multi-project landing zones<\/li>\n<li>standard templates and developer self-service portals<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform Engineer<\/li>\n<li>Cloud Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Cloud Security Engineer (especially IAM governance)<\/li>\n<li>Solutions Architect (designing standard patterns and controls)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>There is no \u201cConfig Connector certification\u201d as a standalone credential. Relevant Google Cloud certifications often include:\n&#8211; Professional Cloud Architect\n&#8211; Professional Cloud DevOps Engineer\n&#8211; Professional Cloud Security Engineer<br\/>\nVerify current certification tracks on Google Cloud\u2019s official certification site.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a namespace-per-project model and provision:<\/li>\n<li>buckets + IAM<\/li>\n<li>Pub\/Sub topics\/subscriptions + IAM<\/li>\n<li>service accounts per app<\/li>\n<li>Add policy enforcement:<\/li>\n<li>deny public access<\/li>\n<li>enforce required labels and naming<\/li>\n<li>Implement GitOps:<\/li>\n<li>PR validation + automatic sync to the cluster<\/li>\n<li>Create a \u201cbreak-glass\u201d pattern:<\/li>\n<li>separate admin namespace and restricted RBAC<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Access and resource management<\/strong>: Practices and controls for who can do what (access) and how cloud resources are created\/managed (resource management).<\/li>\n<li><strong>CRD (CustomResourceDefinition)<\/strong>: Extends Kubernetes API with new resource types.<\/li>\n<li><strong>Controller \/ reconciliation<\/strong>: A loop that continuously drives actual state toward desired state.<\/li>\n<li><strong>Desired state<\/strong>: The configuration you declare in Kubernetes objects.<\/li>\n<li><strong>Drift<\/strong>: When the real resource differs from declared configuration.<\/li>\n<li><strong>GKE (Google Kubernetes Engine)<\/strong>: Managed Kubernetes service on Google Cloud.<\/li>\n<li><strong>GSA (Google Service Account)<\/strong>: Google Cloud identity used by services and automation.<\/li>\n<li><strong>KSA (Kubernetes Service Account)<\/strong>: Kubernetes identity used by pods.<\/li>\n<li><strong>Workload Identity<\/strong>: GKE feature that maps KSA identities to GSA identities without keys.<\/li>\n<li><strong>Namespaced mode<\/strong>: Config Connector management model that uses namespaces for isolation and delegation.<\/li>\n<li><strong>Cluster mode<\/strong>: Config Connector management model where resources are managed cluster-wide.<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: Google Cloud logging for administrative and data access events.<\/li>\n<li><strong>Least privilege<\/strong>: Grant only the minimum permissions required.<\/li>\n<li><strong>GitOps<\/strong>: Operating model where Git is the source of truth and automation applies changes.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Config Connector (Google Cloud) is a Kubernetes-native way to manage Google Cloud resources declaratively, making it especially relevant for <strong>Access and resource management<\/strong> programs that need consistent IAM and resource provisioning with strong auditability.<\/p>\n\n\n\n<p>It matters because it brings <strong>reconciliation, GitOps workflows, and Kubernetes RBAC<\/strong> to Google Cloud infrastructure management\u2014helping teams reduce drift, standardize provisioning, and implement governance guardrails at scale.<\/p>\n\n\n\n<p>Cost-wise, Config Connector\u2019s biggest drivers are <strong>GKE cluster runtime<\/strong> and the <strong>resources you provision<\/strong>, plus observability and potential networking costs in private environments. Security-wise, the most important decisions are using <strong>Workload Identity<\/strong>, enforcing <strong>least privilege<\/strong>, and restricting who can apply infrastructure CRDs via <strong>Kubernetes RBAC and admission policy<\/strong>.<\/p>\n\n\n\n<p>Use Config Connector when Kubernetes is already your operational backbone and you want to manage Google Cloud resources with the same operational model. Next step: work through the official overview and resource reference, then build a small GitOps pipeline to manage a controlled set of resource kinds:\n&#8211; https:\/\/cloud.google.com\/config-connector\/docs\/overview\n&#8211; https:\/\/cloud.google.com\/config-connector\/docs\/reference\/overview<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Access and resource management<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[52,51],"tags":[],"class_list":["post-533","post","type-post","status-publish","format-standard","hentry","category-access-and-resource-management","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/533","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=533"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/533\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=533"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=533"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=533"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}