Проксируем файлы из AWS S3 средствами nginx18.10.2018 09:48

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

narwnpom7q_0ddhmxxalre-etq0.png

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


  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’а на основе разных параметров клиента или запроса.

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

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

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


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

{
    "Version": "2012-10-17",
    "Id": "http custom auth secret",
    "Statement": [
        {
            "Sid": "Allow requests with my secret.",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket-for-habr/*",
            "Condition": {
                "StringLike": {
                    "aws:UserAgent": [
                        "xxxyyyzzz"
                    ]
                }
            }
        }
    ]
}


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

  • "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.


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

© Habrahabr.ru