Aws CloudFront Malformed Policy

Question

Я пытаюсь создать подписанный 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, иногда это может быть Поместить объект, иногда это может быть объект удаления. Как достичь этого в облачном фронте?

Answer 1

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

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

Отзыв Creating a Policy Statement for a Signed URL That Uses a Custom Policy для правильного формата этих политик.

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

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

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

Или просто отправьте другие запросы непосредственно в ведро.