CloudFront с поддержкой S3 и подписанные URL-адреса

Question

Первоначально я настроил S3 bucket "bucket.mydomain.com" и использовал CNAME в своем DNS, чтобы я мог извлекать файлы оттуда, как если бы это был поддомен.Это работало для http с:

bucket.mydomain.com/image.jpg

или с https как:

s3.amazonaws.com/bucket.mydomain.com/image.jpg

Некоторые файлы в этом контейнере были общедоступными, но некоторые были «прочитаны с проверкой подлинности», так что мне пришлось бысгенерируйте подписанный URL с истечением срока действия, чтобы их можно было прочитать / загрузить.

Я хотел иметь возможность использовать https без имени amazon в URL, поэтому я установил дистрибутив CloudFront с корзиной S3 в качествепроисхождение.Теперь я могу использовать https как:

bucket.mydomain.com/image.jpg

Проблема, с которой я столкнулся сейчас, заключается в том, что мне кажется, что либо все мои файлы в корзине должны быть общедоступными, либо все они должны быть прочитаны с проверкой подлинности.

Как я могу заставить подписанные URL-адреса использоваться для некоторых файлов, но другие файлы должны быть общедоступными?

Answer 1

Описание Майкла хорошо.Amazon также заявил (ссылка ниже): «Подпись версии 2 устарела, и окончательная поддержка подписи версии 2 прекратится 24 июня 2019 года».

https://docs.aws.amazon.com/AmazonS3/latest/dev/auth-request-sig-v2.html

Answer 2

кажется, что либо все мои файлы в корзине должны быть доступны для публичного чтения, либо все они должны быть аутентифицированы для чтения

То есть - вроде- исправить, по крайней мере, в простой конфигурации.

CloudFront имеет функцию, называемую Origin Access Identity (OAI), которая позволяет ему проверять подлинность запросов, отправляемых в ваше ведро.

CloudFront такжеподдерживает управление доступом зрителей к вашим ресурсам с помощью подписанных URL-адресов CloudFront (и подписанных файлов cookie).

Но эти две функции не зависят друг от друга.

Если настроен OAI, он всегда отправляет информацию об аутентификации в корзину независимо от того, является ли объект закрытым или общедоступным.

Аналогично, если вы включите Ограничить доступ для просмотра для поведения кэша CloudFront всегда будет требовать подписи запросов средства просмотра, независимо от того, является ли объект закрытым или общедоступным (в корзине), потому что CloudFront не знает.

Есть несколько вариантов.

Если ваш контент логически разделен по пути, решение простое: создайте несколько вариантов поведения кэша с соответствующими шаблонами пути, такими как /public/* или /private/*, и настройте их для отдельного соответствующего ограниченного доступа для просмотра.настройки.Независимо от того, является ли объект общедоступным в корзине, не имеет значения, поскольку CloudFront будет выполнять сквозные запросы для (например) /public/*, не требуя подписанного URL-адреса, если это поведение кэша не «ограничивает доступ для просмотра».По умолчанию вы можете создать 25 уникальных шаблонов поведения кэша.

Если это не решение, вы можете создать два дистрибутива CloudFront.Один будет без OAI и без включенного Restrict Viewer Acccess.Этот дистрибутив может получать только открытые объекты.Второй дистрибутив будет иметь OAI и потребует подписанных URL-адресов.Вы можете использовать это для частных объектов (это будет работать и для публичных объектов - но им все равно понадобятся подписанные URL-адреса).Здесь не будет никакой разницы в цене, но у вас могут возникнуть проблемы с несколькими источниками.

Или вы можете изменить свое приложение так, чтобы оно подписывало все URL-адреса для иного общедоступного контента при отображении HTML (или ответов API).или какой бы ни был контекст для ваших ссылок).

Или, в зависимости от архитектуры вашей платформы, возможно, существуют другие более сложные подходы, которые могут иметь смысл, в зависимости от сочетания публичного и частного и вашего желаниядобавить немного интеллектуальности с помощью триггеров Lambda @ Edge, которые могут выполнять такие вещи, как проверка / изменение запросов в полете, обращение к внешней логике и источникам данных (например, поиск файла cookie сеанса в DynamoDB), перехват ошибок и генерирование перенаправлений.