Skip to content
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

Add s3 canned ACL support #189

Closed
wants to merge 1 commit into from

Conversation

ivanmp91
Copy link
Contributor

@ivanmp91 ivanmp91 commented Aug 11, 2020

Changing default canned ACL[1] would be useful for situations where the S3 bucket is located in a different account. For S3, by default the object owner is the source AWS account where the object comes from [2]. This is a big limitation for a disaster recovery scenario where the restore could be done in a different account and requires to previously change the permissions to all objects in the bucket.

The default ACL value will remain as private.

[1] https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#canned-acl
[2] https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-owner-access/

┆Issue is synchronized with this Jira Task by Unito
┆friendlyId: K8SSAND-1406
┆priority: Medium

@adejanovski
Copy link
Contributor

Hi @ivanmp91,

we had a small git problem which made us rewrite history in master...
Could you please reset your master branch and rebase this branch on top of it?

Thanks and sorry for the inconvenience!

@ivanmp91
Copy link
Contributor Author

Hi @ivanmp91,

we had a small git problem which made us rewrite history in master...
Could you please reset your master branch and rebase this branch on top of it?

Thanks and sorry for the inconvenience!

Sure! This is done @adejanovski

@adejanovski
Copy link
Contributor

Hi @ivanmp91,

there are a lot of commits in this PR that would need squashing and cleaning up.
Could you rebase on top of the latest master, drop the commits that are part of this PR but were not written by you, and squash the remaining commits into a single one?
I can do this for you if you're not at ease with this type of manipulations with git.

@@ -73,7 +74,8 @@ def cp_upload(self, *, srcs, bucket_name, dest, max_retries=5):
awscli_output = "/tmp/awscli_{0}.output".format(job_id)
objects = []
for src in srcs:
cmd = [self._aws_cli_path, "s3", "cp", str(src), "s3://{}/{}".format(bucket_name, dest)]
cmd = [self._aws_cli_path, "s3", "cp", "--acl", self.canned_acl,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be backwards compatible with the current behavior if set to private by default?
I seem to understand that it would, but want to make sure of it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, we're moving to a consolidated set of classes for all S3 compatible backends in #272. I'm wondering how this would affect other storage providers than AWS.
I'd be in favor of making this flag added to the aws command line only if canned_acl is set to anything else but private (or maybe we could leave it unset by default).
@burmanm, wdyt?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I only added parameters to the command line if they differ from the default.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adejanovski according to aws s3 documentation, private is the default ACL (https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#canned-acl) which keeping it as a default option if is not set shouldn't change the behavior.

@ivanmp91 ivanmp91 force-pushed the add-s3-canned-acl branch 5 times, most recently from 6a32f5d to a94d329 Compare February 8, 2021 18:37
Copy link
Contributor

@adejanovski adejanovski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking this PR again after a while 😅
Thanks for your incredible patience @ivanmp91

I'll go ahead and merge.

@adejanovski
Copy link
Contributor

ouch there are some conflicts we need to handle before it can be merged.

@rzvoncek
Copy link
Contributor

Closing in favour of #779

@rzvoncek rzvoncek closed this Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants