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] [Updated] (AIRAVATA-2840) Group-based authz applied to credential store tokens (was: Secure GroupResourceProfiles from being cloned and repurposed)
Date Wed, 12 Sep 2018 18:37:00 GMT

     [ https://issues.apache.org/jira/browse/AIRAVATA-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marcus Christie updated AIRAVATA-2840:
--------------------------------------
    Summary: Group-based authz applied to credential store tokens (was: Secure GroupResourceProfiles
from being cloned and repurposed)  (was: Secure GroupResourceProfiles from being cloned and
repurposed)

> Group-based authz applied to credential store tokens (was: 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