Run operator with RoleBinding

• Which image of the operator are you using? e.g. registry.opensource.zalan.do/acid/postgres-operator:v1.10.0
• Where do you run it - cloud or metal? Kubernetes or OpenShift? OpenStack Kubernetes
• Are you running Postgres Operator in production? no
• Type of issue? question

I'm trying to run the operator while keeping resources as namespace bound as possible. For configuration I've set watched_namespace: "" to watch the current namespace only. For RBAC, ClusterRoles are required although I'm wondering if the operator can run with a RoleBinding instead of a ClusterRoleBinding.

I've tried changing the postgres-operator CRB to a RB in the example manifests and see the following log messages from the operator:

W0424 19:20:36.158731       1 reflector.go:424] github.com/zalando/postgres-operator/pkg/controller/controller.go:493: failed to list *v1.Node: nodes is forbidden: User "system:serviceaccount:default:postgres-operator" cannot list resource "nodes" in API group "" at the cluster scope
E0424 19:20:36.158757       1 reflector.go:140] github.com/zalando/postgres-operator/pkg/controller/controller.go:493: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User "system:serviceaccount:default:postgres-operator" cannot list resource "nodes" in API group "" at the cluster scope

As the ClusterRole still provides list & watch rules for node resources, I'm not sure what's causing these errors. The operator is still able to function (seemingly) and can create, update, and destroy Postgres clusters.

While I don't believe this is an actively supported configuration, I'd appreciate input on what may be causing these errors or if anyone else has a similar preference for namespace-level resources over cluster-wide ones.

Start with the example RBAC manifests and inspect pkg/controller/controller.go around line 493, where the node informer reports the forbidden access. Trace which resources the operator watches at cluster scope and compare them with the namespace-bound RoleBinding. Done should establish whether this configuration is supported and identify the required scope or documentation change.