Вопрос: Amazon Cloudfront с S3. Доступ закрыт


Мы пытаемся распространять ведра S3 через Cloudfront, но по какой-то причине единственным ответом является XML-документ AccessDenied, такой как:

<Error>
    <Code>AccessDenied</Code>
    <Message>Access Denied</Message>
    <RequestId>89F25EB47DDA64D5</RequestId>
    <HostId>Z2xAduhEswbdBqTB/cgCggm/jVG24dPZjy1GScs9ak0w95rF4I0SnDnJrUKHHQC</HostId>
</Error>

Вот настройки, которые мы используем:

Distribution Settings Origin Settings

И вот политика для ведра

{
    "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/*"
        }
    ]
}

65
2018-03-11 12:32


Источник


Настройки поведения кэша - imgur.com/JBZqrRm - Jordan Adams
Убедитесь, что Cloudfront может считывать из ведра S3. - Nathan C
Как мне включить или проверить это? - Jordan Adams
Начальные настройки, последний вариант. Смотрите скриншот. :) - Nathan C
Я думаю, что я пробовал это раньше, и это не сработало, но я только что изменил его, и он находится в процессе распространения. Я добавлю политику ведра на свой пост :) - Jordan Adams


Ответы:


Если вы обращаетесь к корню вашего дистрибутива CloudFront, вам нужно установить корневой объект по умолчанию: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html

Чтобы указать корневой объект по умолчанию с помощью консоли CloudFront:

  • Войдите в консоль управления AWS и откройте консоль Amazon CloudFront на https://console.aws.amazon.com/cloudfront/,

  • В списке дистрибутивов в верхней панели выберите дистрибутив для обновления.

  • в Область сведений о рассылке, на Генеральная вкладку нажмите редактировать,

  • в Изменить распространение диалогового окна в Корневой объект по умолчанию введите имя файла корневого объекта по умолчанию.

    Введите только имя объекта, например, index.html, Не добавляйте / перед именем объекта.

  • Чтобы сохранить изменения, нажмите Да, Редактировать,


58
2017-10-16 23:12





У меня была такая же проблема, и в то время как ответ Куши разрешает проблему для index.html в корневом пути моя проблема заключалась также в подкаталогах, поскольку я использовал те, которые были объединены с index.html для получения «хороших URL-адресов» (example.com/something/, а не «уродливый» example.com/something.html)

Частично это также вина Amazon, потому что, когда вы настроите дистрибутив CloudFront, он предложит вам выборки S3, но если вы выберете один из них, он будет использовать URL-адрес ведра, а не статический URL-адрес хостинга веб-сайта в качестве бэкэнд.

Поэтому, чтобы исправить проблему:

  • Включить статический хостинг веб-сайтов для ведра
  • Установить Индекс (и, возможно ошибка) надлежащим образом
  • копия Конечная точка URL - вы можете найти его рядом с вышеуказанными настройками - он должен выглядеть примерно так: <Bucket.name> .s3-website- <AWS-область> .amazonaws.com
  • Используйте этот URL как источник распространения CloudFront. (Это также сделает CF Корневой объект по умолчанию установка ненужная, но не мешает установить ее в любом случае)

36
2018-05-11 14:01



Отличный ответ на дату этого комментария. - Sai Ramachandran


У меня была такая же проблема, как @Cezz, хотя это решение не помогло бы в моем случае.

Как только статический хостинг веб-сайтов включен для этого ведра, это означает, что пользователи могут получать доступ к контенту либо через URL-адрес Cloudfront, либо URL-адрес S3, что не всегда желательно. Например, в моем случае дистрибутив Cloudfront имеет SSL, и пользователи не должны иметь доступ к нему через соединение, отличное от SSL.

Решение, которое я нашел, состояло в следующем:

  • сохранить статический хостинг веб-сайтов в корзине S3
  • сохранить источник распространения Cloudfront как идентификатор S3
  • установите «Ограничить доступ к ведро» на «Да» (и для удобства, чтобы CloudFront автоматически обновлял политику ведра)
  • на «Страницы ошибок», создайте настраиваемый ответ и сопоставьте код ошибки «403: Запрещено» с требуемой страницей ответа i.e./index.html с кодом ответа 200

Обратите внимание, что в моем случае я обслуживаю одностраничное приложение javascript, где все пути разрешены index.html. Если у вас есть пути, которые разрешают разные объекты в вашем ведре S3, это не сработает.


6
2017-11-18 14:01



Спасибо за Ваш ответ. Этот работал для меня. У меня была такая же проблема, как и вы. Я не хотел, чтобы люди обращались к моему ведомому S3, поэтому мне нужно было ограничить доступ к S3 Origin, который работает только при заполнении источника, как это было предложено автозаполнением в Cloudfront. Одностороннее замечание, однако, вам не нужно отключать статический хостинг веб-сайтов. Простое удаление политики ведра, которая позволяет получить доступ общественности. - Torsten
Это было действительно полезно, запрещенное сообщение поступает из S3, которое я не понимал вначале, поэтому вам нужно поймать это с помощью специальной страницы ошибок, чтобы ваш SPA работал. - Ivan


В моем случае я использовал несколько истоков с поведением «Path Pattern» вместе с Origin Path в моем ведре S3:

Плохая настройка:

Поведение CloudFront: /images/* -> My-S3-origin

My-S3-происхождения: Происхождение: /images

Файлы S3: /images/my-image.jpg

Запрос GET: /images/my-image.jpg -> 403

Что происходит, так это то, что весь запрос CloudFront GET отправляется в начало: /image/my-image.jpg с префиксом Origin Path: /images, поэтому запрос на S3 выглядит так: /images/images/my-image.jpg которого нет.

Решение

удалить исходный путь.

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


2
2017-11-08 01:10