2

I have a bucket in one account and I am trying to copy the content from this bucket to another bucket in another account:

Here I found: AWS S3 copy files and folders between two buckets

The following command:

aws s3 sync s3://mybucket-src s3://mybucket-target

does the trick. But the problem is when I copy an image in the destination bucket I see:

enter image description here

So as you can see the encryption is changed to access denied from none. So now when I even try to make the image public manually it does not work and I cannot even open the image.

Can anyone help what my problem is?

Here is my policy on target:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAll", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::xxxxxxxxxxxx:root", "" ] }, "Action": "", "Resource": [ "arn:aws:s3:::test", "arn:aws:s3:::test/*" ] } ] }

Also the default encryption is none on both buckets

Update: One more thing that might give a clue: I tested on another account with the same s3 set up and worked but those two accounts the same issue. I am not sure though what would be the issue since I am not even using encryption on s3. I think something is going on on account set up or maybe it is a bug in aws

Update:

One more thing I also noticed that the owner of the file copied in the new account is still the last account. So it is referencing to the last owner

Hamed Minaee
  • 2,480
  • 4
  • 35
  • 63

1 Answers1

2

My answer assumes that you have the S3 objects encrypted using KMS Managed Keys (SSE-KMS).

You have two choices:

  1. Redo the copy decrypting the files before storing unencrypted in the destination bucket.
  2. Share encryption keys between accounts.

How to enable cross-account access to existing custom keys.

In the KMS console, click the custom key alias for which you want to enable cross-account access.

In the Key Usage section, look for the External Accounts subsection, and click Add External Account. Type the 12-digit AWS account ID of the account that you want to be able to use this key. Repeat this process for each additional external account you want to add. Click Save Changes when you are done.

Share Custom Encryption Keys

John Hanley
  • 74,467
  • 6
  • 95
  • 159
  • Thanks for the information, this is really helpful. But when I look at my images in the source I see that encryption is none which I think means that the files are stored without encryption. Do u think encryption happens when copy happens? – Hamed Minaee Nov 13 '17 at 22:41
  • If the source object is not encrypted, then look at the S3 policies in the destination account. Encryption might be enabled as a default action but you don't have access to the encryption keys. – John Hanley Nov 13 '17 at 22:44
  • Here is my policy:{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAll", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::xxxxxxxxxxxx:root", "*" ] }, "Action": "*", "Resource": [ "arn:aws:s3:::test", "arn:aws:s3:::test/*" ] } ] } How ca I know if there is encryption added? – Hamed Minaee Nov 13 '17 at 22:46
  • What are the S3 and HSM permissions for your account? Can you repeat this as an account logged in with Admin rights? Add this to your question under an EDIT line. – John Hanley Nov 13 '17 at 22:51
  • The default encryption is none on both buckets and running with admin access results the same – Hamed Minaee Nov 13 '17 at 23:08
  • Please confirm that you get "access denied" for Encryption and Tags (your screenshot above) with admin rights. That would make no sense to me. Post your IAM user policy. – John Hanley Nov 13 '17 at 23:12
  • Yes I do get that. My IAM user has admonistrator acces policy the default one in aws: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] } – Hamed Minaee Nov 13 '17 at 23:15
  • Also when I try it between two buckets in one account this never happens and it works fine – Hamed Minaee Nov 14 '17 at 00:15
  • @Hamed. I don't have a clue. I have been trying to reproduce this problem and I cannot. Everything works for me every time. – John Hanley Nov 14 '17 at 00:22
  • One more thing that might give a clue: I tested on another account with the same s3 set up and worked but those two accounts the same issue. I am not sure though what would be the issue since I am not even using encryption on s3 – Hamed Minaee Nov 14 '17 at 01:14
  • One more thing I also noticed that the owner of the file copied in the new account is still the last account. So it is referencing to the last owner – Hamed Minaee Nov 14 '17 at 02:23
  • @Hamed. That is an interesting observation. I will add that to a test scenario tomorrow. – John Hanley Nov 14 '17 at 02:27
  • I think I know what is going on. You copied from the source bucket to the destination bucket while using credentials of the source account user. This means that you (source account user) still own the files copied to the destination bucket. The AWS CLI command "aws iam get-user" will tell you the user name of the credentials that you are using. – John Hanley Nov 14 '17 at 02:34
  • Actually very good catch I thought about it 15 mins ago and tested that way and shockingly still the same issues. !!!!!! – Hamed Minaee Nov 14 '17 at 02:40
  • Did you create a new policy in the source bucket allowing the destination bucket owner to access the source bucket files and then using credentials from the destination account repeat the sync command? This way the copied files will be owned by the destination account. – John Hanley Nov 14 '17 at 02:42
  • Yeah actually I gave action:"*" to be on the safe side. Could it be a bug in aws ? – Hamed Minaee Nov 14 '17 at 03:11
  • Oooos I do not know why but when tried with the access key and ... from destination account as you suggested with my python code it works and with cli not. SO I think the issue is fixed. thanks a lot for your help :) – Hamed Minaee Nov 14 '17 at 03:53
  • 1
    The AWS CLI supports multiple profiles. This way you can use credentials for more than one account. look into the "--profile" command line option. – John Hanley Nov 14 '17 at 03:56