Marcus Christie created AIRAVATA-2840:
-----------------------------------------
Summary: Secure GroupResourceProfiles from being cloned and
repurposed
Key: AIRAVATA-2840
URL: https://issues.apache.org/jira/browse/AIRAVATA-2840
Project: Airavata
Issue Type: Bug
Reporter: Marcus Christie
Assignee: Marcus Christie
Email to dev list:
{quote}
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
{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
