gcp-config-connector

Config Connector (KCC) Authoring

A Google Cloud change leaves this agent only one way: as a Config Connector manifest in the GitOps repository, reviewed by a human and applied by the customer's reconciler. This skill writes that manifest. It reads the cluster and the cloud project to decide what to write, validates the result against the CRDs the customer actually runs, and opens the pull request through submit-suggestion. Nothing here mutates a cluster or a project, and the command policy refuses the verbs that would.

When to Use

• A GKE node pool or cluster change — grow or shrink a pool, turn on autoscaling, change a release channel or maintenance window, adopt a cluster the repo does not yet describe.
• A Cloud SQL change — add a read replica, change a tier, enable backups or high availability.
• A VPC firewall rule — open or close a port, narrow a source range, disable a rule, turn on logging.
• Adopting a resource that exists in Google Cloud but has no manifest in the repository (acquisition).

When NOT to Use

• Kubernetes workloads (Deployments, Services, NetworkPolicies): the gke-manifest-generation skill.
• Creating a cluster imperatively with the gke MCP tools or gcloud: the gke-cluster-creation skill.
• A repository whose provisioning/ holds Terraform HCL rather than KCC YAML: say so and stop. This skill authors KRM only.
• Kinds outside the families catalogued in references/. Other Config Connector kinds follow the same annotations and workflow, but their immutable fields are not catalogued here; validate every field with kubectl explain and say in the PR body that the kind is outside the catalogued set.
• Fixing a fleet-audit finding: the fleet-audit skill opens that PR.

Prerequisites (the customer's, not yours)

Config Connector is a customer platform decision. Never propose installing or enabling it; state the missing piece and stop.

1. The CRDs are installed on a cluster your kubeconfig reaches. The check is kubectl get crd <kind-plural>.<group>.cnrm.cloud.google.com (Step 1). No CRD means no schema to validate against and no controller to reconcile the manifest. Stop with: "Config Connector is not installed on <context>; this change needs a KCC-enabled cluster before I can author it."
2. The repository has a KCC path. clusters/<cluster>/provisioning/ in the reference layout, holding YAML with cnrm.cloud.google.com apiVersions. If the repo has no such directory and the user has not named one, ask rather than invent a layout.
3. A namespace bound to a project. The sibling manifests carry either a cnrm.cloud.google.com/project-id annotation on each resource or on the namespace (ConfigConnectorContext). Copy what the siblings do.
4. Read access to the cnrm.cloud.google.com API groups for the create-versus-acquire check. Which identity answers depends on where the KCC objects live: on the management cluster reached in-cluster, the read-only ClusterRole the operator ships grants none of those groups, so kubectl auth can-i says no; on a separate hub reached through get-credentials, the Google service account's IAM permission set decides, and the default read-only set's cluster-viewer role does read custom resources. Either way a no is a fact to report, not an absence to infer from.