[che-operator] - serviceaccount permissions for <username>-che as default namespace

[sparkoo]

Is your enhancement related to a problem? Please describe.

There is an effort to make <username>-che as a default namespace for workspaces (#14795). This should be default option also for che-operator.

This would be quite easy task, but there is issue with permissions. To allow Che to create/use different namespaces for workspaces, than it's deployed to, it needs quite generous cluster-wide permissions. And for che-operator to be able to grant these permissions to che serviceaccount, it has to have this permissions as well. This is tricky as che-operator, to be fully flexible and support all namespace strategies, would have to have the widest permissions, even when it then uses for example OpenShift oAuth, where it does not need any extra permissions.

We have to take in account che-operator deployment with yamls, chectl and OperatorHub. The tricky bit is OperatorHub, where we don't have control how che-operator is deployed and we must choose some reasonable default.

We've came up with this list of permissions https://gist.github.com/sparkoo/624bbd1e10c88b8ad8719b93bc847920

Describe the solution you'd like

deploy che-operator with widest permissions listed here https://gist.github.com/sparkoo/624bbd1e10c88b8ad8719b93bc847920 and create che serviceaccount with limited permissions by given namespace strategy configuration.

We should document, what permissions are needed for chosen namespace strategy and how to remove unused permissions.

che-operator now creates che-workspace serviceaccount in che namespace. Che-server is responsible for this serviceaccount so we should not create it in che-operator. It just has to grant enough permissions to che-server to manage this sa.

Describe alternatives you've considered

• don't use <username>-che as default with che-operator. This could be just documented.
• deploy che-operator with widest permissions, but after CheCluster is deployed, reduce these permissions on itself (I don't know if this is possible. Even if it is, it might be very tricky to not break anything). This would lock the way back to higher-permission namespace strategy.

Additional context

#14795
#15300
che-dev mailing list thread: https://www.eclipse.org/lists/che-dev/msg03491.html
there is draft PR open for this: eclipse-che/che-operator#137

[AndrienkoAleksandr]

Detected issue for minishift #15780

[AndrienkoAleksandr]

Draft: che-incubator/chectl#469