-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manage Access to credentialed-access projects Using Access Point Policies #2293
base: dev
Are you sure you want to change the base?
Conversation
…ring projects with a 'RESTRICTED/CREDENTIALED' access policy.
…s being created for the open data bucket or the controlled data bucket. This update also changes how we grant access to users for the controlled-access dataset by using Access Points (APs). It includes creating and listing APs, creating and updating AP policies, and associating AWS users with APs.
… view to use update_data_access_point_policy instead of the old bucket policy update method. Ensure the S3 credentials exist before updating the data access point policy.
…hen downloading open-access projects.
First observation: the name of the class should probably be Second: we want to associate access points with particular Users, not particular AWS principals. Because:
We could define
Which is essentially the same thing as ManyToManyField at the database level, but at the Python level it gives more flexibility for the future. |
Now, I say this, but to be fair, there is still an open question of whether we want to allow one person to use multiple AWS principals. Doing that, however, could be quite messy UX-wise (we'd either have to tell people "use access point X if you're using principal A, use access point Y if you're using principal B"... or else we'd have to tell people that every time they add a new principal they might be bumped to a different AP.) Anyway, I think if we want to add that feature down the road, we can define new models at that point to support it. |
I don't like having "aws_id" as an argument to To obtain the S3 URI for a particular authorized user, we might end up doing something like
If the region and account ID are required as part of the S3 URI for the access point, those things should be stored in the |
The basic concept here, I think, is to automatically grant access to everyone who has a linked AWS account and has permission to access the project. Still some details need working out, but is that broadly how we want this to work? Or should we instead grant access only to people who request it? I don't think it makes a huge difference, but doing the latter has some advantages: fewer APs to manage, and we get some feedback about how many people are using the feature. |
|
This Pull Request implements the use of AWS S3 Access Point policies to manage access to restricted-access projects stored in S3 buckets.
The key change in this code is to ensure scalability, enabling access management as the number of projects and users grows.