Распределение CloudFront с ответами источника S3 с помощью XML ListBucketResult - PullRequest
Новая
       41

Распределение CloudFront с ответами источника S3 с помощью XML ListBucketResult

0 голосов
/ 25 октября 2018

Мое намерение состоит в том, чтобы мои статические файлы веб-сайта (в React, если это важно) были доступны только через мой домен, а не напрямую через URL-адреса S3.Кажется, он работает на моем собственном компьютере (хотя это может быть кэш CloudFront с тех пор, когда корзина была общедоступной), но другие клиенты получают только сообщения S3 в XML.Запрос домена без какого-либо пути дает ответ.Запрос любого пути (например, /index.html, файл в моем контейнере) дает ответ с кодом NoSuchKey.

Что я делаю неправильно?Вот текущая конфигурация.

  • На маршруте 53 я указываю соответствующий поддомен на дистрибутив CloudFront с записью CNAME (xxxxxxxxxxx.cloudfront.net.)
  • В ACM,У меня есть сертификат, который охватывает поддомен (* .mydomain.com)
  • В CloudFront у меня есть дистрибутив с этими доменными именами (xxxxxxxxxxx.cloudfront.net) и альтернативными доменными именами (subdomain.mydomain.com),- Он включен и находился в развернутом состоянии в течение нескольких часов.
  • У него один источник с именем домена subdomain.mydomain.com.s3.amazonaws.com
  • Я выбралограничить доступ к сегменту и выбрать существующий идентификатор для доступа к источнику.У меня CloudFront было обновление политики корзины сегодня сегодня.
  • В дистрибутиве есть одна запись поведения, которая перенаправляет HTTP на HTTPS и разрешает только методы GET и HEAD
  • Мое имя корзины S3 соответствует записи Route 53(subdomain.mydomain.com)
  • Статический хостинг веб-сайтов включен, и для документов индекса и ошибок установлено значение index.html
  • Политика сегмента была автоматически сгенерирована.Он включает единую идентификационную информацию и ограничивает использование действия s3: GetObject для ресурса arn: aws: s3 ::: subdomain.mydomain.com/*
  • Конфигурация CORS пуста
  • Внутри корзинытакое приложение React с index.html в качестве точки входа.

Редактировать: моя политика корзины ( мне нужно добавить другое действие? ) 

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EZOBXXXXXXXXX"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::subdomain.mydomain.com/*"
        }
    ]
}

1 Ответ

0 голосов
/ 01 ноября 2018

Два изменения получили это работает хорошо. Благодарю Майкла за помощь.

  1. Я изменил разрешения отдельных объектов в моем контейнере S3. Я думал, чтополитика ведра (выше) была достаточной, но оказалось, что это не так.Политика сегмента относится к идентификатору доступа источника (OAI) в CloudFront.Теперь я обращаюсь к каноническому идентификатору пользователя того же идентификатора доступа к источнику при выполнении команды sync в интерфейсе командной строки AWS (CLI). В сценариях package.json : "deploy": "aws s3 sync build/ s3://subdomain.mydomain.com --delete --grants read=id=S3CANONICALIDOFORIGINACCESSIDENTITY"
  2. В своем дистрибутиве CLoudFront я указал Корневой объект по умолчанию как index.html . (Нажмитекнопка Edit на вкладке General . Это сообщает CloudFront, что нужно обслуживать, если он не может сопоставить путь запроса с объектом в корзине S3.Это очень важно для маршрутизации на стороне клиента, как я делаю в React.
  3. Я выдавал недействительные результаты для своего дистрибутива CloudFront против /index.html, а затем почувствовал растерянность, когда мое приложение не обновлялось.Я думаю, что это потому, что, хотя index.html всегда предоставляется пользователям, оно никогда явно не запрашивается.Мои маршруты выглядели как / или /dashboard, которые не были признаны недействительными. Теперь я очищаю кэш CloudFront, делая недействительными /*.
...