Uploaded image for project: 'Red Hat OpenShift Data Science'
  1. Red Hat OpenShift Data Science
  2. RHODS-4928

All the user are able to spawn JH and even is they are not in admin_groups,allowed_groups

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • RHODS_1.15.0_GA
    • UI
    • None
    • False
    • None
    • False
    • Hide

      only allowed users should be able to spawn JH

      Show
      only allowed users should be able to spawn JH
    • N/A
    • Yes
    • No
    • Skip
    • None
    • Medium

      Description of problem:

      In the rhods-groups-config  allowed admin_groups,allowed_groups are 
      ```
      data:
               admin_groups: rhods-admins
               allowed_groups: rhods-users
      ```still, other users are able to spawn the JH 
      example : ldap-noaccess1 is able to spawn JH which belongs to rhods-noaccess group

      Prerequisites (if any, like setup, operators/versions):

      Steps to Reproduce

      1. login to console 
      2. workloads > configMaps > rhods-group-config
      3. change admin_groups,allowed_groups as 
        data:
               admin_groups: rhods-admins
               allowed_groups: rhods-users
      4. restart JH pod 
      5. try to spawn the JH with the user who does not belong to admin_groups,allowed_groups

      Actual results:

          all the User are able to spawn JH 

      Expected results:

      only allowed users should be able to spawn JH

      Reproducibility (Always/Intermittent/Only Once):

      tested on 2 different clusters with ODS 4.11 

      Build Details:

      v1150-10

      Workaround:

      Additional info:

      oc get group                                                                                                                                      
      NAME               USERS
      cluster-admins     htpasswd-cluster-admin-user
      dedicated-admins   ldap-admin3, ldap-admin5, ldap-admin14, ldap-admin15, ldap-admin20, ldap-admin4, ldap-admin6, ldap-admin7, ldap-admin8, ldap-admin9, ldap-admin11, ldap-admin12, ldap-admin17, ldap-admin18, ldap-admin19, ldap-admin1, ldap-admin2, ldap-admin10, ldap-admin13, ldap-admin16
      rhods-admins       kubeadmin, ldap-admin1, ldap-admin2, ldap-admin3, ldap-admin4, ldap-admin5, ldap-admin6, ldap-admin7, ldap-admin8, ldap-admin9, ldap-admin10, ldap-admin11, ldap-admin12, ldap-admin13, ldap-admin14, ldap-admin15, ldap-admin16, ldap-admin17, ldap-admin18, ldap-admin19, ldap-admin20
      rhods-noaccess     ldap-noaccess1, ldap-noaccess2, ldap-noaccess3, ldap-noaccess4, ldap-noaccess5, ldap-noaccess6, ldap-noaccess7, ldap-noaccess8, ldap-noaccess9, ldap-noaccess10, ldap-noaccess11, ldap-noaccess12, ldap-noaccess13, ldap-noaccess14, ldap-noaccess15, ldap-noaccess16, ldap-noaccess17, ldap-noaccess18, ldap-noaccess19, ldap-noaccess20
      rhods-users        kubeadmin, ldap-user1, ldap-user2, ldap-user3, ldap-user4, ldap-user5, ldap-user6, ldap-user7, ldap-user8, ldap-user9, ldap-user10, ldap-user11, ldap-user12, ldap-user13, ldap-user14, ldap-user15, ldap-user16, ldap-user17, ldap-user18, ldap-user19, ldap-user20, ldap-special., ldap-special^, ldap-special$, ldap-special*, ldap-special?, ldap-special[, ldap-special], ldap-special{, ldap-special}, ldap-special@

              lferrnan@redhat.com Lucas Fernandez Aragon
              mwaykole Milind Waykole
              Milind Waykole Milind Waykole
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: