kubernetes/kops · error

applying kubeconfig secret to cluster: %w

Error message

applying kubeconfig secret to cluster: %w

What it means

The kubeconfig Secret (named <cluster>-kubeconfig in kube-system) is applied to the target cluster via server-side apply (ssa). This error wraps any failure of that Patch call, meaning the API server rejected or could not process the apply — e.g. permissions, conflict, validation, or connectivity problems.

Source

Thrown at pkg/controllers/clusterapi/cluster_controller.go:315

			},
			"data": map[string]any{
				"value": kubeconfigBytes,
			},
			"type": "Opaque",
		}

		u := &unstructured.Unstructured{Object: obj}

		// Needed so that capi manager has "permission" to read the secret
		labels := map[string]string{
			"cluster.x-k8s.io/cluster-name": name,
		}

		u.SetLabels(labels)

		setOwnerRef(u, s.Cluster)
		if err := s.ssa(ctx, kube, u); err != nil {
			return fmt.Errorf("applying kubeconfig secret to cluster: %w", err)
		}
	}

	// TODO: Sync with LinkToNetwork
	obj := map[string]any{
		"apiVersion": "controlplane.cluster.x-k8s.io/v1beta1",
		"kind":       "KopsControlPlane",
		"metadata": map[string]any{
			"name":      name,
			"namespace": s.namespace(),
		},
		"spec": map[string]any{},
	}

	u := &unstructured.Unstructured{Object: obj}

	// setOwnerRef(u, s.Cluster)

View on GitHub (pinned to 4c8573c808)

Solutions

  1. Grant the controller RBAC: get/create/update/patch on secrets in kube-system (check +kubebuilder:rbac markers and generated role)
  2. Confirm the kube client points at the intended cluster (KUBECONFIG / in-cluster config)
  3. Inspect the wrapped error: Forbidden → RBAC, Conflict → field-manager conflict, Timeout → connectivity
  4. If a conflicting field manager exists, remove stale managers or adopt the field owner 'cluster-controller'

Example fix

# before: missing RBAC
# (no secrets rule in the controller role)
# after: add to the controller ClusterRole
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
Defensive patterns

Strategy: validation

Validate before calling

// verify RBAC before rollout
kubectl auth can-i patch secrets -n kube-system \
  --as=system:serviceaccount:<ns>:<controller-sa>

Try / catch

if err := s.ssa(ctx, kube, u); err != nil {
    if apierrors.IsForbidden(err) {
        klog.Errorf("RBAC denies secret apply: %v", err)
    }
    return fmt.Errorf("applying kubeconfig secret to cluster: %w", err)
}

Prevention

When it happens

Trigger: The controller's ServiceAccount lacks create/patch RBAC on Secrets in kube-system; another field manager conflicts on the object; the API server is unreachable; the Secret fails server-side-apply validation; namespace kube-system does not exist (wrong kube context).

Common situations: Installing the clusterapi controllers with an incomplete RBAC manifest; applying against the wrong cluster/context; concurrent controllers with different field owners fighting over the secret.

Related errors


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