Marcus: when I say privileges should not be transferred to the clone, I mean the attributes such as an allocation is a PI’s to distribute and not any user’s (to reallocate) in the group who may use part of it. There may be other attributes including access to certain resources (hardware, software, storage etc..) under an allocation that only a PI should be able to control. The users or collaborators in the group should have lesser privileges than the PI. We have to come up with a way to provide the PI such a control.
Thanks, Sudhakar. On Jun 26, 2018, at 8:18 PM, Christie, Marcus Aaron <[email protected]<mailto:[email protected]>> wrote: Hi Sudhakar, On Jun 25, 2018, at 2:12 PM, Pamidighantam, Sudhakar <[email protected]<mailto:[email protected]>> wrote: when you say one can clone, this newly cloned profile will have a separate identity with no privileges available for the original as the user who clones may not inherit those privileges, right?! Well, I’m not quite sure what you mean by privileges. Crucially, a GroupResourceProfile’s GroupComputeResourcePreference defines a login username, a credential store SSH token to use (or it may not specify one and use the gateway default) and optionally an allocation project number. There are other details but these are the more important ones specifying how to access the resource and how to charge jobs submitted. A user who has READ access to such a profile can see all of these details and can recreate a new profile with the same details. If this is the case this should be OK. But we should make sure privileges such as allocations and authorizations are not transferred in the cloning process but need to be set/validated separately. Just hiding may not work as folks with programmatic access may still mess things up. I agree, just hiding may not work, especially since not all fields may be specified since the gateway (in the GatewayResourceProfile) may define some default values here. I’m thinking the more secure approach would be to apply group based authorization to credential store tokens (what I called option #3 in the first email in this thread). This way another user can’t just copy how to authenticate to a compute resource. Thanks, Marcus
