Acacia access and identities

Acacia access and identities

Introduction

Access to Acacia is achieved through S3 credentials, rather than a direct Pawsey username and password login. This page provides some information on the implications of this in terms of user identities and how Acacia projects are structured. It is intended as background information for project administrators seeking to implement access control policies.

Identities in Acacia

When S3 credentials are created using Pawsey’s Origin interface (see https://pawsey.atlassian.net/wiki/x/-E0YAw) the Storage Name will be set to either your Pawsey username or the name of a project (e.g. pawsey0123) of which you are a member.

If S3 credentials were generated with Storage Name set to your Pawsey username, then your Acacia identity will be personal:

arn:aws:iam:::user/<username>

However, if Storage Name was set to the name of a project, then your Acacia identity will be that of the project:

arn:aws:iam::<project-uuid>:

The actual value of project-uuid is shown in Origin when creating S3 credentials for that project.

Your logged-in Acacia identity determines which buckets will be accessible.

Project types

There are two configuration styles for collaborative Acacia projects at Pawsey.

  • group managed allocations (the default)

  • individually managed allocations

There is also a small fixed amount of private storage provided to every user for personal use. This is accessible by creating S3 credentials with the storage class set to the user’s Pawsey username.

Group managed allocations

This is the default configuration for Acacia projects. Here, everyone who is a member of the project as shown in Origin will effectively have the same identity when they use Acacia.

arn:aws:iam::<project-uuid>:

Consequently, there is no way to create policies that can can distinguish between project members and grant different levels of access. However, if we take a user with Pawsey username personA, who is not a member of the project, then you could add a policy that grants them access via the identity:

arn:aws:iam:::user/<personA>

You could control Acacia access by removing all members (except admins) from your Pawsey group project so that you can add them using the above method. However, if your project has access to other resources (e.g. Setonix) then members will lose access to this as well, which may not be desirable.

Individually managed allocations

This is a manual configuration that permits more fine-grained control on Acacia access, and is currently only available by request to the Pawsey Helpdesk. Here, the membership of a project in Origin is not used by the associated Acacia project. Instead, only the PI and admins are granted full access. Regular project members as shown in Origin will have no access to the project’s Acacia allocation. If access is desired, one of the admins must add an explicit policy for the person’s Pawsey identity:

arn:aws:iam:::user/<pawsey-username>

This will allow that person to use S3 credentials, created using their Pawsey username, to access the project according to the specific policy permissions.

Further details and information on how to work with this allocation style are at Work with individually managed allocations.