You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@airavata.apache.org by Thejaka Amila J Kanewala <th...@gmail.com> on 2018/07/01 16:51:24 UTC

Re: Securing GroupResourceProfiles

Hi Marcus,

Sorry for the late reply.

I don't have a better understanding of the functionality provided by
"GroupResourceProfiles".
However, based on your description I understood the following:
"GroupResourceProfiles" has some sensitive details that belong to the
current (user: A) user. Another user (user: B) can clone
"GroupResourceProfiles"
with these sensitive details and can use authentication/ authorization data
from user A.

In my opinion, when cloning "GroupResourceProfiles" to user B space all the
fields that contain sensitive data should be nullified or fill them with
appropriate data for user B (e.g., credential store tokens belonging to
user B). I believe we need to do this for all authentication data in "
GroupResourceProfiles" irrespective of the permission action (READ, WRITE)
attached to "GroupResourceProfiles".

It sounds like "GroupResourceProfiles" is an abstract field which contains
several concrete data fields. In that case, we can handle this in a more
general way by attaching permissions to those concrete data fields.

Hope this makes sense.

Thanks
Thejaka

On Mon, Jun 25, 2018 at 3:57 PM, Christie, Marcus Aaron <ma...@iu.edu>
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

Re: Securing GroupResourceProfiles

Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.

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

On Jul 3, 2018, at 3:12 PM, Christie, Marcus Aaron <ma...@iu.edu>> wrote:

Hi Thejaka,

Yes, that makes sense. For a bit more context: if you are familiar with the existing GatewayResourceProfile, then you’ll find the GroupResourceProfile very similar. We’re transitioning from a GatewayResourceProfile that is implicit shared with all gateway users to a model where there are one or more GroupResourceProfiles that define a set of compute resources that each are shared with one or more groups.

I agree with your assessment. I think we can solve this problem by attaching permissions to the credential store tokens.

Thanks,

Marcus

On Jul 1, 2018, at 12:51 PM, Thejaka Amila J Kanewala <th...@gmail.com>> wrote:

Hi Marcus,

Sorry for the late reply.

I don't have a better understanding of the functionality provided by "GroupResourceProfiles". However, based on your description I understood the following:
"GroupResourceProfiles" has some sensitive details that belong to the current (user: A) user. Another user (user: B) can clone "GroupResourceProfiles" with these sensitive details and can use authentication/ authorization data from user A.

In my opinion, when cloning "GroupResourceProfiles" to user B space all the fields that contain sensitive data should be nullified or fill them with appropriate data for user B (e.g., credential store tokens belonging to user B). I believe we need to do this for all authentication data in "GroupResourceProfiles" irrespective of the permission action (READ, WRITE) attached to "GroupResourceProfiles".

It sounds like "GroupResourceProfiles" is an abstract field which contains several concrete data fields. In that case, we can handle this in a more general way by attaching permissions to those concrete data fields.

Hope this makes sense.

Thanks
Thejaka

On Mon, Jun 25, 2018 at 3:57 PM, Christie, Marcus Aaron <ma...@iu.edu>> 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