Aws CloudFront Неправильная политика

Question

Aws CloudFront Неправильная политика

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

Я использую :

$customPolicy = '{"Id":"Policy1319566876317","Statement":[{"Sid":"Stmt1319566860498","Action":["s3:GetObject"],"Effect":"Allow","Resource":"arn:aws:s3:::my-bucket/*","Principal":{"CanonicalUser":["92cd670939a0460a1b48cbbfedcb5178139bcb315881d9ec3833e497a9e62959762d560feec321a749217754e5d02e5f"]}}]}';// Create a signed URL for the resource using the canned policy
$signedUrlCannedPolicy = $cloudFront->getSignedUrl([
'url'         => $streamHostUrl . '/' . $resourceKey,
'private_key' => base_path().'/'.'mypem file',
'key_pair_id' => 'myid',
'policy' => $customPolicy

]);

По сути, я хочу, чтобы получатель этого подписанного URL имел только те привилегии объекта s3, которые я указываю (в приведенном выше коде он установлен как getObject, иногда это может быть объект, иногда это может быть объект удаления).
Как мне добиться этого в облачном фронте?

0

amazon-cloudfront amazon-s3 amazon-web-services php

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Ваша пользовательская политика выглядит как заявление о политике S3 / IAM. Это не тот документ политики, который используется для подписанных URL-адресов CloudFront. CloudFront имеет совершенно другой язык политики.

Пользовательские политики в CloudFront — технически говоря — разрешить доступ к CloudFront, не ресурсы за этим. Подписанные URL-адреса CloudFront и логика, которая их обрабатывает, не знают о сущностях или конфигурации на задней стороне, таких как имена сегментов, ключи, принципалы, идентификаторы доступа к источнику и т. Д., Они служат только для указания того, что CloudFront разрешен обслуживать запросы для определенного URL или шаблона URL, и ничего более. Они работают строго на «лицевой стороне» CloudFront, и на этом уровне нет информации о том, что происходит за кулисами. Если ваш дистрибутив CloudFront авторизован для выполнения запроса к базовому ресурсу, либо из-за неограниченного доступа к сегменту, либо из-за разрешений, предоставленных идентификатору доступа источника, операция завершается успешно. В противном случае это не удастся.

Обзор Создание заявления о политике для подписанного URL, в котором используется настраиваемая политика для правильного формата для этих политик.

По сути, если вы хотите использовать подписанные URL-адреса CloudFront, другие операции с корзиной, а не GETто вы, скорее всего, пытаетесь использовать подписанные URL-адреса CloudFront способом, несовместимым с их дизайном.

Операции, кроме GET, HEAD, а также OPTIONS «можно» отправить на S3 через CloudFront, но для этого есть только одна причина — перебраться по высококачественным путям из пограничной сети в исходное местоположение S3. дела PUT CloudFront на самом деле ничего не хранит в CloudFront — он просто передает запрос в корзину и не влияет на то, что уже может быть кэшировано в CloudFront.

Вы можете достичь той же цели — повысить производительность глобальной сети и пропускную способность наGET операции — с помощью S3 ускорение передачи который выставляет ваше ведро на https://example-bucket.s3-accelerate.amazonaws.com когда вы включаете функцию. Я делаю небольшое упрощение, но, по сути, это ставит ваше ведро за общий дистрибутив CloudFront, который не кэшируется, что позволяет вам использовать сеть Edge для более быстрой передачи, но при этом использовать стандартные сигнатуры и политики S3 для достижения того, что вы делаете. нужен для всех других операций S3.

Или просто отправьте остальные запросы прямо в корзину.

1