The current flow of deployment in RHODS creates un-necessary friction due to the current authorization defaults. 

Currently, most customers are going to: 

1) enable the RHODS add-on

2) access the RHODS dashboad

3) be unable to spawn a notebook (403: forbidden) 

4) google the issue (https://www.google.com/search?q=rhods+403+forbidden) 

5) hopefully find this page (https://access.redhat.com/documentation/en-us/red_hat_openshift_data_science/1/html-single/getting_started_with_red_hat_openshift_data_science/index#i_see_a_emphasis_role_strong_403_forbidden_emphasis_error_when_i_log_in_to_jupyterhub) 

6) create those groups

7) add the right users in the groups

8) be grumpy about having to add each new user to this list. 

With the RHODS add-on soon to be enabled for any OSD/ROSA customer, we should fix this asap in order to retain as many customers as we can and limit unnecessary Cases from being open. 

Currently, the default content for the rhods-group-config configmap is https://github.com/red-hat-data-services/odh-deployer/blob/main/groups/groups.configmap.yaml 

apiVersion: v1
kind: ConfigMap
metadata: 
  labels: 
    opendatahub.io/modified: "false"
    app: jupyterhub
  name: rhods-groups-config
data: 
  admin_groups: "rhods-admins"
  allowed_groups: "rhods-users"

I recommend we change the last 2 lines to: 

  admin_groups: "dedicated-admins"
  allowed_groups: "system:authenticated"

This change would mean that, out of the box: 

• Any dedicated admin is also a RHODS admin
• Any OpenShift User is also a RHODS user

Customers who find that this is too much can spend some time reading the doc, on how to manage users and groups to be more restrictive.
But by default, I see no reason to limit the RHODS userbase. 

(any OpenShift user can already create pods in their own namespaces anyways.) 

We should investigate this quickly and see if this can be implemented in time for RHODS being made available to all OSD/ROSA customers. 

I'm happy to demo or discuss the pros/cons.