[Feature] Generate Harvester cloud provider kubeconfig using terraform resource

[avekrivoy]

Is your feature request related to a problem? Please describe.

According to the documentation, the first step in integrating the downstream Rancher cluster with the Harvester cloud provider is to create a service account in the Harvester cluster and "associate" kubeconfig with it. This kubeconfig has to be passed as argument to machine_selector_config block of a rancher2_cluster_v2 resource.

Service account must be created manually using an API call (curl). Would be nice to have a terraform resource that implements this feature

Describe the solution you'd like

Ideally, it would be great to have a resource that takes k8s cluster namespace and service account as parameters and returns kubeconfig associated with the service account.

[matttrach]

Hello! Thanks for the suggestion! sorry for the late reply, is this still valuable?

[avekrivoy]

Hello! I found a workaround using the Terracurl module, but this is still valuable.

[derhornspieler]

+1 on this — hit the same gap today (2026-04-20) rebuilding an RKE2-on-Harvester cluster via rancher2_cluster_v2. Posting a concrete example and a proposed API shape in case it helps the maintainers prioritize.

Current workflow (what users have to do today)

1. Shell-out to Harvester's POST /k8s/clusters/<harvester-id>/v1/harvester/kubeconfig endpoint with body:

   {
     "clusterRoleName": "harvesterhci.io:cloudprovider",
     "namespace": "<vm-ns>",
     "serviceAccountName": "<cluster-name>"
   }

   typically from a bash wrapper invoked via null_resource / local-exec.

2. Write the returned kubeconfig to a file and either commit it to the repo or stash it somewhere file() can read.

3. Pass it through machine_selector_config.config.cloud-provider-config:

   resource "rancher2_cluster_v2" "rke2" {
     # ...
     rke_config {
       machine_selector_config {
         config = yamlencode({
           cloud-provider-config = file("./harvester-cloud-provider-kubeconfig")
           cloud-provider-name   = "harvester"
         })
       }
     }
   }

The Rancher UI performs steps 1–3 automatically when you pick Harvester as both infrastructure and cloud provider, so the backend capability already exists — this is purely a TF-surfacing gap.

Failure mode this causes

When the baked-in kubeconfig's SA token expires (SA tokens default to 1h in modern Kubernetes / with TokenRequestProjection), the in-cluster harvester-cloud-provider pod starts 401ing against Harvester. New nodes never get their node.cloudprovider.kubernetes.io/uninitialized taint removed, cattle-cluster-agent stays Pending, and terraform apply can't repair the drift because the kubeconfig is a static file() input. Recovery requires re-running the curl wrapper and re-applying.

Proposed API shapes

Option A — data source (lightweight, composable):

data "rancher2_harvester_cloud_provider_kubeconfig" "this" {
  cloud_credential_id  = rancher2_cloud_credential.harvester.id
  cluster_role_name    = "harvesterhci.io:cloudprovider"   # default
  namespace            = var.vm_namespace
  service_account_name = var.cluster_name
}

resource "rancher2_cluster_v2" "rke2" {
  # ...
  rke_config {
    machine_selector_config {
      config = yamlencode({
        cloud-provider-config = data.rancher2_harvester_cloud_provider_kubeconfig.this.kubeconfig
        cloud-provider-name   = "harvester"
      })
    }
  }
}

Option B — dedicated nested block on rancher2_cluster_v2 (mirrors the UI wizard):

resource "rancher2_cluster_v2" "rke2" {
  harvester_cloud_provider {
    cloud_credential_id  = rancher2_cloud_credential.harvester.id
    vm_namespace         = var.vm_namespace
    service_account_name = var.cluster_name
    # kubeconfig is generated and baked into chart_values internally
  }
}

Either shape eliminates the external shell script, the need to commit a kubeconfig file, and the silent-drift failure mode when the SA token rotates.

Why it still matters

The author's workaround using Terracurl (noted above) works but:

• Keeps a secret-bearing kubeconfig in TF state / on disk rather than letting the provider treat it as ephemeral.
• Doesn't trigger re-generation on token expiry — the Terracurl request only re-runs when its triggers change, so drift is invisible until the next node provisioning attempt fails.
• Requires every consumer of this pattern to reinvent the same wrapper. I searched issues on this repo for harvester cloud-provider kubeconfig / harvesterhci cloudprovider / harvester cloud provider and this ticket is the only one tracking the feature — the duplication isn't theoretical.

Happy to contribute a PR for Option A (data source) if maintainers confirm the design. Option B is nicer ergonomically but wider in blast radius and probably needs an HEP-style review first.

[derhornspieler]

Hello! Thanks for the suggestion! sorry for the late reply, is this still valuable?

Yes 100% as this would allow IaC deployments to set VMs as required for VM migration vs Harvester using default option of shutting down VM if migration fails.

A VMI shutdown for one's running RKE2 nodes is disruptive and can be disasterous. Esp if the VMI is replaced or auto scale added and that evictionStrategy cannot be set for node groups.