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, 19 Sep 2018 14:46:00 GMT

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

Marcus Christie updated AIRAVATA-2840:
--------------------------------------
    Description: 
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}



h2. Proposed API methods
* (breaking change) generateAndRegisterSSHKeys(authzToken, description)
* (breaking change) registerPwdCredential(authzToken, loginUserName, password, description)
* (new) getCredentialSummary(authzToken, tokenId)
* (new) getAllCredentialSummaries(authzToken, type)
* remove getSSHPubKey - use getCredentialSummary instead
* remove getAllGatewaySSHPubKeys - use getAllCredentialSummaries instead
* remove getAllCredentialSummaryForGateway - use getAllCredentialSummaries instead
* remove getAllCredentialSummaryForUsersInGateway - use getAllCredentialSummaries instead
* remove getAllGatewayPWDCredentials - use getAllCredentialSummaries instead
* (unchanged) deleteSSHPubKey
* (unchanged) deletePWDCredential


h2. Proposed Credential Store CPI methods
* (new) getAllCredentialSummaries(type, accessibleTokenIds, gatewayId)
* remove getAllCredentialSummaryForGateway
* remove getAllCredentialSummaryForUserInGateway
* remove getAllSSHKeysForUser
* remove getAllSSHKeysForGateway
* remove getAllPWDCredentialsForGateway

h2. Proposed data model changes
* remove CredentialOwnerType. The credential owner will be registered in the sharing registry.
"GATEWAY" credentials will be those created and shared with users in the Admins group. Credentials
that users create will be visible to admins as well and anyone else they want.

h2. TODO
[x] Update migration script
[ ] Test migration script
[ ] Add {{getAllCredentialSummaries(type, accessibleTokenIds, gatewayId)}} to credential store
[ ] Update API server methods to register credentials with sharing registry and query sharing
registry for allowed credentials

  was:
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}



h2. Proposed API methods
* (breaking change) generateAndRegisterSSHKeys(authzToken, description)
* (breaking change) registerPwdCredential(authzToken, loginUserName, password, description)
* (new) getCredentialSummary(authzToken, tokenId)
* (new) getAllCredentialSummaries(authzToken, type)
* remove getSSHPubKey - use getCredentialSummary instead
* remove getAllGatewaySSHPubKeys - use getAllCredentialSummaries instead
* remove getAllCredentialSummaryForGateway - use getAllCredentialSummaries instead
* remove getAllCredentialSummaryForUsersInGateway - use getAllCredentialSummaries instead
* remove getAllGatewayPWDCredentials - use getAllCredentialSummaries instead
* (unchanged) deleteSSHPubKey
* (unchanged) deletePWDCredential


h2. Proposed Credential Store CPI methods
* (new) getAllCredentialSummaries(type, accessibleTokenIds, gatewayId)
* remove getAllCredentialSummaryForGateway
* remove getAllCredentialSummaryForUserInGateway
* remove getAllSSHKeysForUser
* remove getAllSSHKeysForGateway
* remove getAllPWDCredentialsForGateway

h2. Proposed data model changes
* remove CredentialOwnerType. The credential owner will be registered in the sharing registry.
"GATEWAY" credentials will be those created and shared with users in the Admins group. Credentials
that users create will be visible to admins as well and anyone else they want.


> 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}
> h2. Proposed API methods
> * (breaking change) generateAndRegisterSSHKeys(authzToken, description)
> * (breaking change) registerPwdCredential(authzToken, loginUserName, password, description)
> * (new) getCredentialSummary(authzToken, tokenId)
> * (new) getAllCredentialSummaries(authzToken, type)
> * remove getSSHPubKey - use getCredentialSummary instead
> * remove getAllGatewaySSHPubKeys - use getAllCredentialSummaries instead
> * remove getAllCredentialSummaryForGateway - use getAllCredentialSummaries instead
> * remove getAllCredentialSummaryForUsersInGateway - use getAllCredentialSummaries instead
> * remove getAllGatewayPWDCredentials - use getAllCredentialSummaries instead
> * (unchanged) deleteSSHPubKey
> * (unchanged) deletePWDCredential
> h2. Proposed Credential Store CPI methods
> * (new) getAllCredentialSummaries(type, accessibleTokenIds, gatewayId)
> * remove getAllCredentialSummaryForGateway
> * remove getAllCredentialSummaryForUserInGateway
> * remove getAllSSHKeysForUser
> * remove getAllSSHKeysForGateway
> * remove getAllPWDCredentialsForGateway
> h2. Proposed data model changes
> * remove CredentialOwnerType. The credential owner will be registered in the sharing
registry. "GATEWAY" credentials will be those created and shared with users in the Admins
group. Credentials that users create will be visible to admins as well and anyone else they
want.
> h2. TODO
> [x] Update migration script
> [ ] Test migration script
> [ ] Add {{getAllCredentialSummaries(type, accessibleTokenIds, gatewayId)}} to credential
store
> [ ] Update API server methods to register credentials with sharing registry and query
sharing registry for allowed credentials



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message