Ok you saying use ‘cluster-admin’ role instead of cluster ‘admin’ role to robot to satisfy all use cases. Yes we want to have robot to setup resources quotas, limits and other works along with projects creation.
-- Srinivas Kotaru From: David Eads <[email protected]<mailto:[email protected]>> Date: Friday, August 5, 2016 at 4:45 AM To: skotaru <[email protected]<mailto:[email protected]>> Cc: Tobias Florek <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: cluster-roles You have to have `oc policy add-cluster-role-to-user admin robot` in order for the robot to later do `oc policy add-role-to-user admin srinivas -n project01`. Otherwise, the REST request will be rejected as escalating. Granting `oc policy add-cluster-role-to-user admin robot` (grants powers for project scoped resources in all projects) is very different from `oc policy add-cluster-role-to-user cluster-admin robot` (grants powers for all resources including nodes, users, groups, etc). A second role is required to grant robot the power to create resourcequotas and limitranges because a normal "admin" can't mutate those resources. On Thu, Aug 4, 2016 at 9:07 PM, Srinivas Naga Kotaru (skotaru) <[email protected]<mailto:[email protected]>> wrote: Hmm this is what I understood from both David and you. Options 1: 1. Grant Cluster “admin” role to robot account (not cluster-admin but just cluster ‘admin’ role) 2. Robot user being used (token) to create/modify/delete project1 3. Grant user1 to project admin access. Once user1 has project admin access, user1 can him self grant project admin/edit/view roles to his team mates 4. Setup quota limits etc at project1 level by robot user Option 2: 1. Create a custom role with required rules to robot account 2. Repeat above steps Am not sure what is the difference between cluster-admin Vs admin roles at cluster bindings. After looking at role bindings, cluster-admin has more power then admin roles Please confirm whether my understanding above is correct or not. -- Srinivas Kotaru On 8/4/16, 2:48 PM, "[email protected]<mailto:[email protected]> on behalf of Tobias Florek" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: >Hi Srinivas, > >I don't think you got the David's points. In order to grant "admin" to >any other user, the user granting needs to have (at least) admin >privileges. If this account should do that in any project, it will need >admin privileges in any project. > >I hope I explained it in a coherent manner. > >Good luck with the setup, > Tobi(as Florek) > >_______________________________________________ >users mailing list >[email protected]<mailto:[email protected]> >http://lists.openshift.redhat.com/openshiftmm/listinfo/users _______________________________________________ users mailing list [email protected]<mailto:[email protected]> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
