What causes "error finding Machine with providerID %q: %w" in kubernetes/kops?

Check connectivity and RBAC from the verifier to the CAPI management cluster's API server

error finding Machine with providerID %q: %w

Error message

error finding Machine with providerID %q: %w

What it means

When the instance carries the CAPG role label, VerifyToken looks up the corresponding Cluster API Machine by providerID (gce://project/zone/instance). This error wraps any failure from FindMachineByProviderID, typically a Kubernetes API error reaching the management cluster or an internal lookup failure.

Source

Thrown at upup/pkg/fi/cloudup/gce/tpm/gcetpmverifier/tpmverifier.go:169

	capgRole := instance.Labels[gce.LabelKeyCAPIRoleName]

	if clusterName == "" {
		return nil, fmt.Errorf("could not determine cluster for instance %s", instance.SelfLink)
	}

	if clusterName != v.opt.ClusterName {
		return nil, fmt.Errorf("clusterName does not match expected: got %q, want %q", clusterName, v.opt.ClusterName)
	}

	var capiMachine *clusterapi.Machine

	if v.capiManager != nil && capgRole != "" {
		providerID := "gce://" + tokenData.GCPProjectID + "/" + tokenData.Zone + "/" + tokenData.Instance

		m, err := v.capiManager.FindMachineByProviderID(ctx, providerID)
		if err != nil {
			return nil, fmt.Errorf("error finding Machine with providerID %q: %w", providerID, err)
		}
		capiMachine = m
	}

	// Check if this is a CAPG managed instance
	if instanceGroupName == "" && capiMachine == nil {
		return nil, fmt.Errorf("could not determine ownership for instance %s", instance.SelfLink)
	}

	// Verify the token has a valid GCE TPM signature.
	{
		// Note - we might be able to avoid this call by including the attestation certificate (signed by GCE) in the claim.
		tpmSigningKey, err := v.getTPMSigningKey(ctx, &tokenData)
		if err != nil {
			return nil, err
		}

		if !verifySignature(tpmSigningKey, token.Data, token.Signature) {

View on GitHub (pinned to 4c8573c808)

Solutions

Check connectivity and RBAC from the verifier to the CAPI management cluster's API server
Verify a Machine object exists whose spec.providerID exactly equals gce://<project>/<zone>/<instance>
Confirm CAPG version produces providerIDs in the same gce://project/zone/name format
Retry if the API server error was transient

Defensive patterns

Strategy: retry

Validate before calling

// check a Machine exists for this providerID before verification
pid := "gce://" + proj + "/" + zone + "/" + name
m, err := capiManager.FindMachineByProviderID(ctx, pid)
if err != nil { return fmt.Errorf("CAPI lookup not possible: %w", err) }
if m == nil { return fmt.Errorf("no Machine with providerID %s", pid) }

Try / catch

m, err := capiManager.FindMachineByProviderID(ctx, providerID)
if err != nil {
    if isTransient(err) { time.Sleep(backoff); retry() }
    return fmt.Errorf("error finding Machine with providerID %q: %w", providerID, err)
}

Prevention

Ensure the verifier has working kubeconfig/RBAC to list Machines in the management cluster
Keep CAPG and kops versions aligned on providerID format
Monitor management cluster API health from the verifier
Apply retry with backoff for transient API server errors

When it happens

Trigger: capiManager is non-nil and the instance has the CAPG role label, but FindMachineByProviderID returns an error: management cluster API unreachable, RBAC denied listing Machines, or the providerID index lookup fails.

Common situations: CAPG management cluster API server down or unreachable from the verifier; missing RBAC permissions for Machines; providerID format drift between CAPG versions (e.g. zone vs region mismatch in the gce:// URI).

Related errors

AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/bfb6fca6f2ab3814. Report an issue: GitHub.