Operator's own ClusterRole is missing almost all required permissions

[makbill]

Summary

The operator's own ClusterRole (<release>-manager-role-cluster, rendered when watchNamespaces is
empty / cluster-wide, which is the default) only grants get/list on openclawclusterdefaults.
It's missing permissions for openclawinstances, openclawselfconfigs, and every child resource
the controller creates — so a fresh install cannot reconcile any OpenClawInstance at all out of
the box.

Environment

• Chart: oci://ghcr.io/paperclipinc/charts/openclaw-operator, version 0.38.3 (appVersion 0.38.3)
• Install method: helm install openclaw-operator oci://ghcr.io/paperclipinc/charts/openclaw-operator --set webhook.enabled=true --set metrics.serviceMonitor.enabled=true
• Kubernetes: v1.35.5+k3s1 (k3s/k3d)

Steps to reproduce

1. helm install the chart with default watchNamespaces: [] (cluster-wide).
2. Apply a minimal OpenClawInstance.
3. kubectl logs deploy/openclaw-operator -n openclaw-operator-system

Actual behavior

Immediately on startup, the controller's informers fail to even list the CRD it's supposed to
manage:

failed to list *v1alpha1.OpenClawInstance: openclawinstances.openclaw.rocks is forbidden:
User "system:serviceaccount:openclaw-operator-system:openclaw-operator" cannot list resource
"openclawinstances" in API group "openclaw.rocks" at the cluster scope

Once that's worked around, reconciliation proceeds but fails again, one resource type at a time,
for every child resource kind: statefulsets, deployments, services, configmaps, secrets,
serviceaccounts, persistentvolumeclaims, events, jobs, cronjobs, networkpolicies,
ingresses, poddisruptionbudgets, horizontalpodautoscalers, roles, rolebindings,
httproutes.gateway.networking.k8s.io, servicemonitors.monitoring.coreos.com,
prometheusrules.monitoring.coreos.com.

Inspecting the rendered ClusterRole:

$ kubectl get clusterrole <release>-manager-role-cluster -o yaml
rules:
- apiGroups: [openclaw.rocks]
  resources: [openclawclusterdefaults]
  verbs: [get, list]

That's the entirety of the operator's own cluster-scoped grant. By contrast, the chart does
correctly generate <release>-aggregate-to-admin/edit/view ClusterRoles with full
openclawinstances/openclawselfconfigs permissions — but those are aggregated into the
built-in admin/edit/view roles for human users, not bound to the operator's own
ServiceAccount.

Expected behavior

The operator's own ClusterRole should include everything its reconcile loop actually touches —
presumably the full kubebuilder-marker-generated rule set is meant to land in the "manager"
ClusterRole/Role, but appears to have been dropped for the cluster-scoped rendering path.

Workaround used

Created a supplemental ClusterRole/ClusterRoleBinding granting the operator's ServiceAccount
(openclaw-operator-system:openclaw-operator) full CRUD on all of the above resource types, kept
outside Helm's ownership so it survives helm upgrade.

Related: watchNamespaces scoping is also broken

Separately, setting watchNamespaces: [my-namespace] (to render namespaced Role/RoleBinding
instead of cluster-scoped) causes the operator to watch its own namespace
(openclaw-operator-system) for child resources instead of the target namespace:

failed to list *v1.Deployment: deployments.apps is forbidden: User
"...openclaw-operator" cannot list resource "deployments" in API group "apps"
in the namespace "openclaw-operator-system"

Reverting to the cluster-wide default (watchNamespaces: []) was the only way to get reconciliation
working, even though single-namespace scoping is otherwise a reasonable thing to want for tighter
RBAC.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If this issue is still relevant, please leave a comment or remove the stale label.

[stubbi]

Thanks for the detailed report. Splitting it, because the two halves landed differently.

The primary claim doesn't reproduce. Rendering the chart at defaults (watchNamespaces: [], cluster-wide) with your exact flags produces <release>-manager-role — no -cluster suffix — carrying the full kubebuilder rule set: statefulsets, deployments, services, configmaps, secrets, serviceaccounts, persistentvolumeclaims, events, pods, jobs, cronjobs, roles/rolebindings, networkpolicies/ingresses, httproutes, poddisruptionbudgets, horizontalpodautoscalers, servicemonitors/prometheusrules, and openclawinstances/openclawselfconfigs with status and finalizers. Verified against the v0.38.3 tag as well, so it isn't a post-release fix.

The name you pasted is the tell: <release>-manager-role-cluster only renders on the watchNamespaces-non-empty branch, and on that branch it is deliberately narrow — it exists only to grant the cluster-scoped OpenClawClusterDefaults, because a namespaced Role can't (#529). The per-namespace Role carries everything else.

Your "Related" section is the real bug, and it's fixed. That one reproduces exactly, and it explains both symptoms:

cmd/main.go added the operator's own namespace to the cache's DefaultNamespaces so it could read s3-backup-credentials. DefaultNamespaces applies to every watched type, so it also started Deployment, StatefulSet, Service and ConfigMap informers in openclaw-operator-system — which the namespaced Roles correctly don't grant, since the operator manages no children there. Hence your error verbatim:

failed to list *v1.Deployment: deployments.apps is forbidden: ...
cannot list resource "deployments" in API group "apps"
in the namespace "openclaw-operator-system"

#591 scopes only the Secret informer to that namespace and renders a matching Secret-only Role there, leaving everything else bound to watchNamespaces. Single-namespace scoping should work now without the supplemental ClusterRole.

One thing that would help close this out: can you confirm whether your install actually had watchNamespaces set (values file, or a previous --set on the release)? Everything you observed is consistent with namespaced mode, and if so, the ClusterRole half was a red herring rather than a second defect.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If this issue is still relevant, please leave a comment or remove the stale label.