boto3 дает 403s: нужно ли что-то модифицировать, чтобы boto3 S3 работал в регионах S3?

Question

У меня были лямбды из одного региона (us-west-2), получающие 403 за операции S3 (HeadObject, PutObject, CopyObject) против объектов в корзине из другого региона (ca-central-1).Симулятор политики заверил меня, что операции должны работать в соответствии с моей политикой, но явно было что-то еще.Эта политика привязана к роли, и у меня есть доверительные отношения между лямбдой и этой ролью.

Одна из попыток, которые я предпринял для решения этой проблемы, состояла в том, чтобы указать имя региона, добавив его к имени сегмента.

, т. Е. Изменив:

head_object(Bucket="foo", ...)

на (немного) более квалифицированное наименование:

head_object(Bucket="foo.us-west-2", Key="bar")

Интересно, что это изменило бы 403 на 404.

Я наткнулся на этот обходной путь (?) через догадки, основываясь на требуемой структуре заголовка хоста и intro: работа с сегментами .Но это натянуто.

Я не могу найти ссылку в документах, где перечислены различные принятые формы имен сегментов (например, от простого имени до полностью определенного ARN).Доступен ли список поддерживаемых форматов для указания имен сегментов и ключей?

Добавление .<region> к имени сегмента позволит HeadObject работать по-разному, но PutObject и CopyObject завершатся неудачно с NoSuchBucket если я попробую тот же трюк.Возможно, каждый вызов API S3 имеет разный синтаксис для указания регионов источника и назначения?

Я включил политику, привязанную к роли моей лямбды.Может быть, есть что-то конкретное, что мешает межрегиональным операциям, как это было предложено в комментариях?Мои исходные и конечные сегменты не имеют прикрепленной политики сегментов.Лямбда и два сегмента принадлежат одной и той же учетной записи.

У лямбды есть роль со следующей политикой:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3Ops",
            "Effect": "Allow",
            "Action": [
                "s3:DeleteObjectTagging",
                "s3:DeleteObjectVersion",
                "s3:GetObjectVersionTagging",
                "s3:DeleteObjectVersionTagging",
                "s3:GetObjectVersionTorrent",
                "s3:PutObject",
                "s3:GetObjectAcl",
                "s3:GetObject",
                "s3:GetObjectTorrent",
                "s3:AbortMultipartUpload",
                "s3:GetObjectVersionAcl",
                "s3:GetObjectTagging",
                "s3:GetObjectVersionForReplication",
                "s3:DeleteObject",
                "s3:GetObjectVersion"
            ],
            "Resource": [
                "arn:aws:s3:::a-specific-bucket-1/*",
                "arn:aws:s3:::a-specific-bucket-2/*",
                "arn:aws:s3:::*/*",
                "arn:aws:logs:*:*:*"
            ]
        },
        {
            "Sid": "AllowLogging",
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:*:*"
        },
        {
            "Sid": "AllowPassingRoleToECSTaskRoles",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*"
        },
        {
            "Sid": "AllowStartingECSTasks",
            "Effect": "Allow",
            "Action": "ecs:RunTask",
            "Resource": "*"
        },
        {
            "Sid": "AllowCreatingLogGroups",
            "Effect": "Allow",
            "Action": "logs:CreateLogGroup",
            "Resource": "arn:aws:logs:*:*:*"
        }
    ]
}

Примечание. Я использовал оба символа подстановкии конкретные имена сегментов в списке ресурсов.Раньше у меня были только конкретные имена, а затем я добавлял шаблоны для проверки.

Примечание: Это очень связано с этим вопросом на S3 403s .Хотя принятый ответ, кажется, утверждает, что он связан с корректировкой политики, я думаю, что это просто вопрос квалификации именования ресурсов.

Answer 1

Существует многоуровневый ответ на этот вопрос.

Документация по таким параметрам, как последний API AmazonS3 , полезна, но есть различия в том, как имена регионов указываются в разных языковых библиотеках..

Например, в Boto3 (python) имена контейнеров всегда можно указывать в их краткой форме, независимо от региона, в котором они находятся.

Тот факт, что выполнение client.head_object(Bucket=short_name, Key="foo") вернул a403, но то, что client.head_object(Bucket=short_name + ".us-west-2", Key="foo") вернуло 404, является чем-то вроде красной сельди .Boto3 выполняет плохую проверку, на мой взгляд.Добавление суффикса региона заставит boto3 по-разному анализировать параметры - часть имени сегмента окажется в пути запроса:

# short form (my-bucket) - 403 forbidden
Starting new HTTPS connection (1): my-bucket.s3.ca-central-1.amazonaws.com
[INFO] Starting new HTTPS connection (1): my-bucket.s3.ca-central-1.amazonaws.com
[DEBUG] "HEAD /foo HTTP/1.1" 403 0

# short form + region ("my-bucket.us-west-2") -- 404 not found
# the bucket name has moved to the request Path (wrong!)
Starting new HTTPS connection (1): s3.us-west-2.amazonaws.com
[DEBUG] "HEAD /my-bucket.us-west-2/hosts HTTP/1.1" 404 0

Я обнаружил одну корневую проблему с политикой.Изменение:

"Resource": [
            "arn:aws:s3:::a-specific-bucket-1/*",
            "arn:aws:s3:::a-specific-bucket-2/*",
            "arn:aws:s3:::*/*",
            "arn:aws:logs:*:*:*"
]

и добавление :::* устраняет проблему кросс-области.т. е. я добавил одну строку к предыдущему блоку, чтобы получить это:

"Resource": [
            "arn:aws:s3:::a-specific-bucket-1/*",
            "arn:aws:s3:::a-specific-bucket-2/*",
            "arn:aws:s3:::*/*",
            "arn:aws:s3:::*"       <--- *this line*
            "arn:aws:logs:*:*:*"
]

Эта модификация позволила успешно выполнить эти запросы на несколько групп.Потом я немного поигрался с симулятором политики и заметил, что добавленная строка также необходима для поддержки операций HeadBucket или ListBucket.

Кроме того, учитывая, что первые две строки в этом ресурсеблоки являются избыточными после добавления записи с подстановочными знаками, они могут быть опущены без какого-либо эффекта для получения окончательной версии:

"Resource": [
            "arn:aws:s3:::*/*",
            "arn:aws:s3:::*"
            "arn:aws:logs:*:*:*"
]

Примечание. Я не проверял, включает ли :::* :::*/*.Вполне возможно, что :::* делает :::*/* избыточным.Я подозреваю, что */* интерпретируется как означающее что-либо внутри ведра, но не само ведро.

Примечание: я думаю, что, возможно, я тоже слишком быстро спешил к (неправильному) выводу, что это крестпроблема региона, из-за изменения кода состояния.Сначала я провел некоторые тесты против a-specific-bucket-1 и a-specific-bucket-2, которые работали нормально (потому что они были жестко заданы в политике), и так случилось, что первое новое ведро (отличное от этих двух), в котором я получил ошибки, оказалосьв другом регионе.Третье ведро в том же регионе могло бы дать мне 403 секунды.