airavata-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Christie (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AIRAVATA-2840) Secure GroupResourceProfiles from being cloned and repurposed
Date Fri, 20 Jul 2018 18:26:00 GMT

    [ https://issues.apache.org/jira/browse/AIRAVATA-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16551102#comment-16551102
] 

Marcus Christie commented on AIRAVATA-2840:
-------------------------------------------

Final summarizing email:
{quote}
Hi Dev,

Just to document, I discussed this with Sudhakar and we decided that securing access to the
credential store tokens should be sufficient to secure GroupResourceProfiles from being copied
and misused.  Only users who have READ access to a credential store token will be able to
use that token to create a GroupResourceProfile.

This would still allow a gateway admin to simplify the process of allowing users with their
own allocation to create a GroupResourceProfile that shares that allocation with other users
in the gateway. The process would work something like this:
1. Gateway admin create a new credential store token and shares it with the user who has his/her
own allocation (e.g., a faculty user).
2. Gateway admin adds the credential store token’s public key in a community account on
one or more compute resources.
3. The gateway admin then either creates the GroupResourceProfile and shares it with the user,
or instructs the user to create a GroupResourceProfile with the specific credential store
token and login username for one or more compute resources.
4. Gateway user does so and plugs in the allocation number for each compute resource.
5. Gateway user adds the gateway community user account to their allocation.

Really, steps 1-4 could be done by the gateway admin if the user provides the admin with the
allocation number. The only crucial step for the gateway user to complete is to add the community
user account to the allocation.

I’ll be tracking this work in Jira issue AIRAVATA-2840 [1]


Thanks,

Marcus

[1] https://issues.apache.org/jira/browse/AIRAVATA-2840
{quote}

Email thread: http://mail-archives.apache.org/mod_mbox/airavata-dev/201806.mbox/%3c2A405238-6E58-4720-92D7-D6C37592718D@iu.edu%3e

> 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
>            Priority: Major
>
> 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)

Mime
View raw message