Мы пытаемся распространять корзины S3 через Cloudfront, но по какой-то причине единственным ответом является XML-документ AccessDenied, подобный следующему:
<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
<RequestId>89F25EB47DDA64D5</RequestId>
<HostId>Z2xAduhEswbdBqTB/cgCggm/jVG24dPZjy1GScs9ak0w95rF4I0SnDnJrUKHHQC</HostId>
</Error>
Вот настройки, которые мы используем:
А вот политика ведра
{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity *********"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::x***-logos/*"
}
]
}
Если вы обращаетесь к корню вашего дистрибутива CloudFront, вам необходимо установить корневой объект по умолчанию: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html
Чтобы указать корневой объект по умолчанию с помощью консоли CloudFront:
Войдите в Консоль управления AWS и откройте консоль Amazon CloudFront по адресу https://console.aws.amazon.com/cloudfront/.
В списке дистрибутивов на верхней панели выберите дистрибутив для обновления.
в Панель сведений о распространении, на Общее вкладку, щелкните редактировать.
в Изменить распространение диалоговое окно в Корневой объект по умолчанию в поле введите имя файла корневого объекта по умолчанию.
Введите только имя объекта, например, index.html
. Не добавляйте / перед именем объекта.
Чтобы сохранить изменения, нажмите Да, редактировать.
У меня была такая же проблема, и хотя ответ Куши действительно решает проблему для index.html в корневом пути моя проблема была также с подкаталогами, поскольку я использовал их в сочетании с index.html чтобы получить "красивые URL" (example.com/something/, а не "уродливые" example.com/something.html)
Частично это также вина Amazon, потому что при настройке распространения CloudFront он предложит вам на выбор корзины S3, но если вы выберете одну из них, в качестве серверной части будет использоваться URL-адрес корзины, а не статический URL-адрес хостинга веб-сайта.
Итак, чтобы исправить проблему:
У меня была та же проблема, что и у @Cezz, но в моем случае решение не сработало.
Как только для сегмента включен статический хостинг веб-сайтов, это означает, что пользователи могут получать доступ к контенту либо через URL Cloudfront, либо через URL S3, что не всегда желательно. Например, в моем случае в распространении Cloudfront включен SSL, и пользователи не должны иметь к нему доступ через соединение без SSL.
Решение, которое я нашел, заключалось в следующем:
Обратите внимание, что в моем случае я обслуживаю одностраничное приложение javascript, в котором все пути разрешаются index.html. Если у вас есть пути, которые разрешаются к различным объектам в вашей корзине S3, это не сработает.
В моем случае я использовал несколько источников с поведением "Path Pattern" вместе с Origin Path в моем ведре S3:
CloudFront Поведение: /images/*
-> My-S3-origin
My-S3-origin: Путь происхождения: /images
Файлы S3: /images/my-image.jpg
Запрос GET: /images/my-image.jpg -> 403
Произошло то, что весь запрос GET CloudFront был отправлен источнику: /image/my-image.jpg
с префиксом Origin Path: /images
, поэтому запрос в S3 выглядит как /images/images/my-image.jpg
которого не существует.
удалить исходный путь.
Это позволило мне получить доступ к корзине с идентификатором доступа источника и разрешениями корзины, а также ограниченными разрешениями для отдельных файлов.
В моем случае я неправильно настроил Route 53. Я создал псевдоним в своем домене, но указал его на S3 Bucket вместо распространения CloudFront.
Также я пропустил корневой объект по умолчанию. Консоль действительно может быть улучшена, если к тексту вопросительного знака добавить немного информации о потенциальных последствиях ее пропуска.