The fuse-online install procedure consists of:
1. syndesis install --setup (as cluster-admin)
2. syndesis install --grant ${user} (as cluster-admin)
3. syndesis install (as ${user})

The reason for step 2 is the necessary binding of roles and cluster-roles to ${user}. See here.

It may be possible to eliminate this step and allow for ${user} to acquire the necessary privileges without needing these explicit bindings. This would be more in line with how the operator is installed via the OperatorHub (the latter having no concept of the grant step at all).

During experimentation with kustomize and fuse-console, I was introduced the following labels:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: hawtio-operator-installer
labels:
#

1. Add these permissions to the "admin" and "edit" default roles
2. to allow namespace admin user access hawtio api
   #
   rbac.authorization.k8s.io/aggregate-to-admin: "true"
   rbac.authorization.k8s.io/aggregate-to-edit: "true"
   ...

These labels allow for aggregated cluster-roles which means that explicit bindings are unnecessary (see fuse-console install procedure). This implies that a binding to ${user} is not necessary as long as they are a namespace admin; the result being that ${user} gets the cluster-role's permissions as a consequence of being an admin.

Therefore, may be possible with a bit of moving around, we could apply this labelling to fuse-online's operator resources and effectively remove the grant step.

This has the following implications:

• Removal of --grant parameter;
• Removal of --cluster parameter (all roles would be cluster-roles by default)
• The service-account for operator-install does require an explicit binding & therefore would be installed with --setup (something already done by the CSV when installing via OperatorHub).