Спасительный флажок bucket-owner-full-control, решающий вопросы доступа в #s3 бакет для двух аккаунтов, не поможет для ситуации с тремя и более аккаунтами. Это когда файл копируется из аккаунта A в бакет аккаунта B, а после нужно расшарить это для аккаунта C (также имеющего доступ в бакет аккаунта B).
Использование --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 для получения файла, однако такое (переключение в роль) не всегда возможно сделать в уже имеющемся ПО и библиотеках.

При ошибках в работе с #S3 бакетами есть некоторый набор вещей, что требуется проверить, чтобы найти причину и всё исправить. Очевидные проблемы доступа (не настроенные права) не в счёт, как и вопросы шифрования (это отдельная тема). Далее выстраданные болью и болью вещи.

===
Некоторые достаточно очевидные, что нужно перебрать и проверить.
===

• регион бакета - он может отличаться от того, из которого идёт доступ

• в современных регионах - только Signature Version 4

• популярные ошибки в #IAM: не стоит политика на бакет без * (звёздочки, wildcard):

"Action": [
    "s3:GetObject",
    "s3:ListBucket",
],
"Resource": [
    "arn:aws:s3:::my-bucket",
]

... или наоборот (только с *)

"Action": [
    "s3:GetObject",
    "s3:ListBucket",
],
"Resource": [
    "arn:aws:s3:::my-bucket/*",
]

• есть операция с каталогом, а нет политики 's3:ListBucket'

===
Некоторые не самые и совсем неочевидные (из серии #magic).
===

• сильно отличается время на инстансе (в любую сторону - несколько минут и больше), что часто даёт #error:

A client error (403) occurred when calling the HeadObject operation: Forbidden

• версия #aws_cli старая (локально на старых виртуалках)

• стоит флажок --recursive, а работа идёт с файлом (может возникнуть после копипаста в скриптах) — в результате ничего не будет - ни ошибки (что самое противное), ни копирования файла

• при операциях с https - нужно учитывать заголовки в CORS (что есть HEAD среди них, который часто по дефолту не стоит)

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

• проверяем доступ на конкретный файл с помощью

aws s3api get-object-acl --bucket my-bucket --key my-path/some.file

... если получаем ошибку:

An error occurred (AccessDenied) when calling the GetObjectAcl operation: Access Denied

... хотя точно есть все права/роли для бакета (на другой аккаунт, нужные операции и путь), то значит файлы в бакете имеют хозяина, недоступного запрашиваемому — см. выше про #shared_bucket
В нормальной ситуации был бы ответ типа:

{
"Owner": {
"DisplayName": "my-dev",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "my-dev",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Permission": "FULL_CONTROL"
},
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "jenkins",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Permission": "FULL_CONTROL"
}
]
}

... где перечислены все owner-ы файла. Итого (при такой ошибке) нужно перезалить файл с owner-ом аккаунта, откуда идёт чтение, либо изменить (добавить) owner-а или же переключаться в роль аккаунта, где есть права для операции чтения.

#s3_debug

Как было раньше? (с момента создания S3 в 2004-м году)

Для решения этой проблемы использовался ключик bucket-owner-full-control, который добавлял на копируемый объект "Permission": "FULL_CONTROL" для владельца аккаунта бакета.

Скопируем файл из аккаунта А в бакет аккаунта В:

aws --profile=account-A s3 cp file.txt s3://my-bucket-account-B/

Смотрим права сохранённого объекта:

aws --profile=account-A s3api get-object-acl --bucket my-bucket-account-B --key file.txt
{
"Owner": {
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Permission": "FULL_CONTROL"
}
]
}

Файл лежит в бакете аккаунта В, но полный владелец (Owner) лишь у аккаунта А. Владелец В ничего не сможет сделать с файлом (но будет платить за него).

Теперь скопируем файл с ключиком bucket-owner-full-control:

aws --profile=account-A s3 cp file.txt s3://my-bucket-account-B/ --acl bucket-owner-full-control

Теперь права изменились:

{
"Owner": {
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Permission": "FULL_CONTROL"
},
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "account-B",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Permission": "FULL_CONTROL"
}
]
}

В список Grantee имеющий полный доступ FULL_CONTROL добавился и аккаунт В.

Но владелец Owner по-прежнему аккаунт А!

Чем это плохо? Какая разница — владелец или полные права?

Для аккаунта В без разницы. Но как только вы попытаетесь скачать этот файл из аккаунта С (который также имеет все права на работу с бакетом В) — получите отлуп! И понятно почему — ведь ему владелец файла из аккаунта А не разрешал доступ к объекту, его нет в списке Grantee.

На этом неочевидном, сложном и крайне неприятном косяке сильно валились и валятся многие мульти-аккаунтные проекты. Тонкие вещи с добавлением прав аккаунту С с помощью флажка --grant-full-control это весьма специфичный и редко возможный вариант.

И как теперь?

Теперь, если включить для бакета S3 Object Ownership = bucket owner preferred, то при копировании файла без флажка bucket-owner-full-control ничего не изменится. А вот с ним - произойдёт чудо:

{
"Owner": {
"DisplayName": "account-B",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",


    "DisplayName": "account-B",
    "ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
   },
   "Permission": "FULL_CONTROL"
  }
 ]
}

Полноправным (и единственным) владельцем (Owner) файла из аккаунта А стал акаунт В! Больше никаких проблем, характерных ранее для #shared_bucket!

Итого

Потому отныне можно рекомендовать всегда включать S3 Object Ownership = bucket owner preferred — логику работы оно не меняет (точней — исправляет), при этом бесплатно и проблем будет меньше.

#S3