AWS Notes
Бывает, что, казалось бы, банальное копирование файлов в #s3 бакет: aws s3 cp ./ s3://some-bucket/files --recursive Когда это происходит из другого аккаунта, когда бакет расположен в другом регионе или с локального компьютера (между бакетами и т.п. не самые…
Спасительный флажок bucket-owner-full-control, решающий вопросы доступа в #s3 бакет для двух аккаунтов, не поможет для ситуации с тремя и более аккаунтами. Это когда файл копируется из аккаунта A в бакет аккаунта B, а после нужно расшарить это для аккаунта C (также имеющего доступ в бакет аккаунта B).
Использование
An error occurred (AccessDenied) when calling the GetObjectAcl operation: Access Denied
Хотя точно у всех есть нужные #IAM #permissions и прописаны правильные #bucket_policy в #shared_bucket.
Дело в тех же owner-ах, как и для "двух-аккаунтной" схемы, только решается много сложней. Объекты в shared-bucket имеют лишь права для этих двух аккаутов A и B, аккаунт C имеет доступ в бакет, но его нет среди owner-ов объектов, потому ничего с ними сделать не может.
Решается ситуация лишь из аккаута owner-а, т.е. из аккаунта A — при копировании нужно добавить в список owner-ов сразу все аккаунты (т.е. в т.ч. C). Обычная #aws_cli команда
my-shared-bucket — бакет в аккаунте B
--key — путь к файлу в этом бакете
--body — локальный путь к файлу (на виртуалке)
--grant-full-control id=s3-canonical-A,id=s3-canonical-B,id=s3-canonical-C — #s3_canonical аккаунтов A, B и C (именно в таком виде - через запятую без пробела, чего нет в доке, враги)
Не нужно путать S3 Сanonical ID с тем, что используется для CloudFront при доступе в непубличный бакет (S3 canonical user ID). Это уникальный ID для аккаунта, который идёт в паре с AWS ID и может быть получен с помощью
"Owner": {
"DisplayName": "my-account-A",
"ID": "d0cecf42b8a1bed065b8a1b2fdbf76c1b6acda99e0338822e3cece21a8c71058"
},
"Buckets": []
...
Это
Потому если нужно раздавать (непубличные) файлы для переменного количества аккаунтов, то #s3 не лучший способ при таком сценарии. В рекомендациях от Амазона это решается с помощью роли в аккаунте A или B, в которую должен переключиться юзер из аккаунта C для получения файла, однако такое (переключение в роль) не всегда возможно сделать в уже имеющемся ПО и библиотеках.
Использование
--acl bucket-owner-full-control не поможет и получим #error:An error occurred (AccessDenied) when calling the GetObjectAcl operation: Access Denied
Хотя точно у всех есть нужные #IAM #permissions и прописаны правильные #bucket_policy в #shared_bucket.
Дело в тех же owner-ах, как и для "двух-аккаунтной" схемы, только решается много сложней. Объекты в shared-bucket имеют лишь права для этих двух аккаутов A и B, аккаунт C имеет доступ в бакет, но его нет среди owner-ов объектов, потому ничего с ними сделать не может.
Решается ситуация лишь из аккаута owner-а, т.е. из аккаунта A — при копировании нужно добавить в список owner-ов сразу все аккаунты (т.е. в т.ч. C). Обычная #aws_cli команда
s3 cp так не умеет — нужно использовать #s3api:aws --region=us-east-1 s3api put-object --bucket my-shared-bucket --key my-bucket-dir/conf.tar.gz --body my-local-dir/conf.tar.gz --grant-full-control id=d0cecf42b8a1bed065b8a1b2fdbf76c1b6acda99e0338822e3cece21a8c71058,id=1208ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb11a9338a60609ee5f9,id=780e8bdf2b68d6cc2da2cfcaa6192fac4f437190322277db24ce81ce9aa698f9Очень непростая и плохо документированная, но рабочая конструкция.
my-shared-bucket — бакет в аккаунте B
--key — путь к файлу в этом бакете
--body — локальный путь к файлу (на виртуалке)
--grant-full-control id=s3-canonical-A,id=s3-canonical-B,id=s3-canonical-C — #s3_canonical аккаунтов A, B и C (именно в таком виде - через запятую без пробела, чего нет в доке, враги)
Не нужно путать S3 Сanonical ID с тем, что используется для CloudFront при доступе в непубличный бакет (S3 canonical user ID). Это уникальный ID для аккаунта, который идёт в паре с AWS ID и может быть получен с помощью
aws s3api list-buckets
{"Owner": {
"DisplayName": "my-account-A",
"ID": "d0cecf42b8a1bed065b8a1b2fdbf76c1b6acda99e0338822e3cece21a8c71058"
},
"Buckets": []
...
Это
ID значение получаем для каждого аккаунта, который должен иметь доступ к данному файлу в shared-bucket. Если потребуется расшарить к новому аккаунту - придётся повторить процедуру для каждого файла (объекта).Потому если нужно раздавать (непубличные) файлы для переменного количества аккаунтов, то #s3 не лучший способ при таком сценарии. В рекомендациях от Амазона это решается с помощью роли в аккаунте A или B, в которую должен переключиться юзер из аккаунта C для получения файла, однако такое (переключение в роль) не всегда возможно сделать в уже имеющемся ПО и библиотеках.