Currently, Strimzi can be installed in two different modes:

• Watching one or more individual namespaces. In this case, most of the RBAC resources need to be set-up only for the namespaces the operator watches. Only the RBAC rights for the cluster-wide resources such as reading the nodes or storage classes or managing cluster role bindings need to be cluster-wide. This works fine in general. But given how the Kubernetes API is designed, the operator here deployes a separate verticle per namespaces with its own watches etc. Due to this, this mode can consume a lot of resources when you want too many namespaces and does not scale well.
• Watching the whole cluster. In this mode, the operator is watching the whole cluster and has access to the whole cluster. All RBAC resources are set-up as cluster wide. This mode works well and does not have any scalability issues related to the number of namespaces in the cluster. This is because it uses only a single operator verticle and only one set watches for the whole cluster. However, in this mode, the operator has also access tot he whole cluster and in theory, it can for example read the secrets in all namespaces. This is something users sometimes wnat to avoid for security reasons.

We can try to make it easier for users to install the operator as cluster-wide but limit the RBAC rights the operator has. We can split the existing role strimzi-cluster-operator-namespaced into too roles:

• The original strimzi-cluster-operator-namespaced
• The new strimzi-cluster-operator-watched

The original role covers the RBAC rights which are needed only in the namespaces where some custom resource is created. The new role contains the RBAC rights which are required as cluster wide for the watches and informers and also to do some basic management of the custom resources (get them, update their status etc.).

Thanks to this split, the users can do the following:

• Deploy the CO as cluster-wide
• Bind the new role strimzi-cluster-operator-watched as cluster-wide
• Bind the strimzi-cluster-operator-namespaced role with role-binding onl for the namespaces, where the user plans to have some operands.

This adds additional complexities for users who want to take this effort. They will be resonsible for managing the RBAC rights and creating the required RoleBindings for the strimzi-cluster-operator-namespaced role. If the user fails to do it, the operator will run into RBAC errors (which will be reflected in the state of the CR in the namespace with missing RBAC). But at the same time, the operator will have less access rights to completely unrelated namespaces, so it might be more secure.

This option does not replace the regular cluster-wide installation. It will be only an expert option for those who want to use this. There will be no special tolling provided for such installation as it is expected the users using this will deal with this in their own way. The split of the cluster roles just makes it much easier for them to install the operator this way.