Cluster-scoped RBAC rules placed in namespaced `permissions` in OLM CSV

[pkoutsovasilis]

Summary

The OLM ClusterServiceVersion generated by ECK places all RBAC rules under spec.install.spec.permissions, which OLM materializes as namespaced Roles and RoleBindings. However, several resources that the operator accesses are cluster-scoped and require ClusterRoles — which OLM only generates from spec.install.spec.clusterPermissions.

As a result, on OwnNamespace and SingleNamespace OLM install modes these rules are silently ineffective: the operator starts without error but cannot access the cluster-scoped resources it depends on.

Affected resources

The following cluster-scoped resources are currently misplaced in permissions instead of clusterPermissions:

Resource	API Group	Used for
namespaces	""	Dynamic namespace selector mode (--managed-namespace-selector)
nodes	""	Exposing node labels as pod annotations (--exposed-node-labels)
validatingwebhookconfigurations	admissionregistration.k8s.io	Webhook certificate management (--manage-webhook-certs, enabled by default)
subjectaccessreviews	authorization.k8s.io	RBAC enforcement on cross-namespace associations (--enforce-rbac-on-refs)
storageclasses	storage.k8s.io	Storage class validation (--validate-storage-class, enabled by default)

Impact

• On AllNamespaces install mode: no impact — OLM generates ClusterRoles from both permissions and clusterPermissions in this mode.
• On OwnNamespace / SingleNamespace install mode: the operator silently loses access to storageclasses, nodes, and subjectaccessreviews. Since --validate-storage-class is enabled by default, this affects every OwnNamespace OLM install.

Fix

Move the cluster-scoped resource rules from permissions to clusterPermissions in hack/operatorhub/templates/csv.tpl. The generator extracts RBAC from config/crds.yaml and config/operator.yaml — the split between permissions and clusterPermissions needs to be made explicit there or applied as a post-processing step in the generator.