Хабрахабр

Проксируем файлы из AWS S3 средствами nginx

Казалось бы, задача реализации фронтенда для AWS на nginx звучит как типовой кейс для StackOverflow — ведь проблем с проксированием файлов из S3 быть не может? На деле выяснилось, что готовое решение не так-то просто найти, и данная статья должна исправить эту ситуацию.

Зачем это вообще может понадобиться?

  1. Контроль доступа к файлам средствами nginx — актуально для концепции IaC (инфраструктура как код). Все изменения, связанные с доступом, будут вноситься только в конфигах, которые лежат в проекте.
  2. Если отдавать файлы через свой nginx, появляется возможность их кэшировать и сэкономить тем самым на запросах к S3.
  3. Подобный прокси поможет абстрагироваться от типа хранилища файлов для разных инсталляций приложения (ведь помимо S3 существуют и другие решения).

Сформулируем рамки

  • Исходный bucket должен быть приватным — нельзя разрешать анонимным пользователям качать файлы напрямую из S3. Если в вашем случае это ограничение не работает, то просто используйте proxy_pass и дальше можете не читать.
  • Настройка со стороны AWS должна быть одноразовой по принципу «настроил и забыл», дабы упростить эксплуатацию.

Ищем решение в лоб

Если ваш оригинальный bucket публичный, то никакие сложности вам не грозят, проксируйте запросы на S3 и всё будет работать. Если же он приватный, то придётся как-то аутентифицироваться в S3. Что нам предлагают коллеги из интернета:

  1. Есть примеры реализации протокола аутентификации средствами nginx. Решение хорошее, но к сожалению, оно рассчитано на устаревший протокол аутентификации (Signature v2), который не работает в некоторых ЦОД Amazon. Если вы попытаетесь воспользоваться этим решением, например, во Франкфурте, то получите ошибку «The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256». Более свежая версия протокола (Signature v4) гораздо сложнее в реализации, а готовых решений для nginx с ней нет.
  2. Есть сторонний модуль для nginx — ngx_aws_auth. Если судить по исходникам, он поддерживает Signature v4. Однако проект выглядит заброшенным: более года отсутствуют изменения в кодовой базе, а также имеется проблема совместимости с другими модулями, на которую не реагирует разработчик. К тому же, добавление дополнительных модулей в nginx — это само по себе зачастую болезненный шаг.
  3. Можно воспользоваться отдельным s3-прокси, коих написано достаточно много. Лично мне понравилось решение на Go — aws-s3-proxy: у него есть готовый и достаточно популярный образ на DockerHub. Но в этом случае приложение обрастёт ещё одним компонентом со своими потенциальными проблемами.

Применяем AWS Bucket Policy

AWS, как правило, пугает новых пользователей своей сложностью и объёмом документации. Но если разобраться, то понимаешь, что он устроен очень логично и гибко. В Amazon'е нашлось решение и для нашей задачи — S3 Bucket Policy. Этот механизм позволяет строить гибкие правила авторизации для bucket'а на основе разных параметров клиента или запроса.


Интерфейс генератора политик — AWS Policy Generator

Вот некоторые интересные параметры, к которым можно привязаться:

  • IP (aws:SourceIp),
  • заголовок Referer (aws:Referer),
  • заголовок User-Agent (aws:UserAgent),
  • остальные — описаны в документации.

Привязка к IP — хороший вариант только при условии, что у приложения есть определённое место жительства, а в наше время это редкость. Соответственно, нужно привязываться к чему-то ещё. В качестве решения я предлагаю сгенерировать секретный User-Agent или Referer и отдавать файлы только тем пользователям, которые знают секретный заголовок. Вот как выглядит подобная политика:

} } ]
}

Немного пояснений:

  • "Version": "2012-10-17" — это внутренняя кухня AWS, которую править не надо;
  • Principal — кого касается данное правило. Можно указать, что оно работает только для определённой AWS-учётки, но в нашем случае стоит "*" — это означает, что правило работает вообще для всех, в том числе и анонимных пользователей;
  • Resource — ARN (Amazon Resource Name) bucket'а и шаблон для файлов внутри bucket'а. В нашем случае политика касается всех файлов, которые лежат в bucket'е example-bucket-for-habr;
  • Condition — здесь указываются условия, которые должны сойтись, чтобы политика заработала. В нашем случае мы сравниваем предустановленный заголовок User-Agent со строкой xxxyyyzzz.

А вот как выглядит работа этого правила с точки зрения анонимного пользователя:

$ curl -I https://s3.eu-central-1.amazonaws.com/example-bucket-for-habr/hello.txt
HTTP/1.1 403 Forbidden
$ curl -I https://s3.eu-central-1.amazonaws.com/example-bucket-for-habr/hello.txt -H 'User-Agent: xxxyyyzzz'
HTTP/1.1 200 OK

Осталось настроить nginx для проксирования:

location /s3-media/ { limit_except GET { deny all; } set $aws_bucket "example-bucket-for-habr"; set $aws_endpoint "s3.eu-central-1.amazonaws.com:443"; set $aws_custom_secret "xxxyyyzzz"; proxy_set_header User-Agent $aws_custom_secret; rewrite ^/s3-media/(.*)$ /$aws_bucket/$1 break; proxy_buffering off; proxy_pass https://$aws_endpoint; }

Заключение

Итого, единожды написав простую политику для bucket'а, мы получили возможность безопасно проксировать файлы с помощью nginx. При этом мы не привязаны по IP и не зависим от дополнительного ПО.

P.S.

Читайте также в нашем блоге:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть