Marcus: 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?! 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.
Thanks, Sudhakar. > On Jun 25, 2018, at 3:57 PM, Christie, Marcus Aaron <[email protected]> wrote: > > Hi All, > > I’m looking for some advice on how to secure GroupResourceProfiles. The > problem is this: any user that has READ access to a GroupResourceProfile can > effectively clone that GroupResourceProfile. This would allow the user to > create a new GroupResourceProfile that uses the same login/allocation and > this new GroupResourceProfile could have fewer restrictions or be shared with > other users. > > Here are some solutions I’m considering: > 1. Create a new permission type that is less privileged than READ and that > gives access to less details. There are a few details in the > GroupComputeResourcePreferences that are sensitive, like loginUserName, > resourceSpecificCredentialToken and allocationProjectNumber, because these > fields determine what account gets charged and these could be left out. > 2. Hide the sensitive fields mentioned above from users with READ access and > only show them to users with WRITE access. > 3. Apply group based authorization to credential tokens and require new > GroupResourceProfiles to have their own credential tokens, that would only be > accessible to the user that creates the GroupResourceProfile. > > I’m open to other ideas. I’m leaning toward #2. The problem with #1 is it > introduces another permission type (READ, WRITE and “USE”?) that will > complicate the user experience. #3 also complicates what is required to > create a GroupResourceProfile. One use case we have in mind is that users who > create a GroupResourceProfile can leverage defaults defined in the > GatewayResourceProfile and thus only need to provide an allocation project > number and not need to add an SSH key to a compute resource account. Approach > #3 would make that more difficult or impossible. > > I hope the above makes sense. Let me know if you have any questions. > > Thanks, > > Marcus
