Как использовать шлюз API в сочетании с микросервисами и JWT?

После полудня,

Просто ищем, чтобы кто-то дважды проверял мою работу. Является ли ниже эффективный способ защиты микросервисов?

Предпосылка

Разрушение нашего монолитного приложения и монолитного Партнерского API в микросервисы, ориентированные на конкретные бизнес-функции. Скорее всего, они будут небольшими приложениями expressjs, работающими в контейнере докеров, на эластичном бобовом стебле, который знает. Они где-то будут жить:)

Я смотрю на то, чтобы встать Kong в качестве моего шлюза API или использовать AWS API Gateway для инкапсуляции деталей моих микросервисов. Кроме того, он просто чувствует себя хорошо.

Плагин JWT для Kong проверит подпись JWT, а затем передаст customer_id в заголовке микросервиса. Я также должен упомянуть, что у нас есть сторонние разработчики, которые также будут участвовать в интеграции. Вот основной пример того, что я вижу:

Реализация

  • Создайте "потребителей" для каждой платформы и стороннего разработчика. (Веб-приложение, мобильное приложение и текущие партнеры по интеграции, которые у нас есть. Примечание: я не хочу создавать пользователей для каждого пользователя, который входит в систему. Хотя это, безусловно, более безопасно, это добавляет много работы. Кроме того, если вы выясните как получить секрет из моего шлюза API. У меня явно есть другие проблемы).
  • Пусть Kong проверит запрос для меня. Вид как вышибала у двери, нет авторизации, просто проверка подлинности.
  • Мне не нужно знать, что токен действителен, когда он попадает в микросервис, я могу просто использовать некоторое промежуточное программное обеспечение для его декодирования и использовать пользовательскую логику, чтобы решить, действительно ли этот пользователь должен делать то, что они пытаются делать.

Дополнительные материалы

  • Там есть хороший плагин контроля доступа для Kong. Наше приложение и мобильное приложение будут работать с привилегиями "Бог", но я определенно мог бы заблокировать разработчиков по определенным маршрутам и методам.

  • Отмена доступа третьей стороны будет простой, отмена доступа конечных пользователей будет не такой простой, если я не хочу сразу аннулировать все JWT, создавая новый секрет. Возможно, я смогу ограничить время токена до 10 минут или около того и сделать наши приложения проверенными, если они истекли, получить новый токен, а затем перейти к исходному запросу. Таким образом, я могу "пометить" их в базе данных или что-то еще, и не позволить генерировать JWT.

  • SSL используется повсеместно, JWT хранится в cookie только для SSL в веб-браузере, и нет никакой конфиденциальной информации, хранящейся в любой формуле.

Спасибо, ребята.

Ответы

Ответ 1

Недавно я работал над решением именно этого вопроса и предпосылки, реорганизации большого монолита в несколько сервисов в архитектуре AWS.

Нет правильного, неправильного или окончательного решения этого вопроса.
Однако мы реализовали решение, очень похожее на решение, описанное выше. Надеюсь, этот ответ может дать хорошее направление для тех, кто смотрит на это в первый раз.

Так мы об этом пошли...

Что нам нужно от шлюза API?

  • Высокодоступный
  • Secure
  • производительным
  • Авторитетный
  • Масштабируемость

Решение 1: AWS API Gateway

профи

  • Высокодоступное управляемое решение.
  • Не нужно беспокоиться о масштабируемости.
  • Поддержка SSL и пользовательских доменов.
  • Авторитет через лямбда и IAM.
  • Играет хорошо с другими службами AWS.
  • Поддерживает управление версиями API из коробки.
  • Простой мониторинг с помощью CloudWatch.

против

  • Трафик не может быть перенаправлен непосредственно во внутреннюю сеть (частный сегмент VPC), то есть потребуется дополнительный шлюз.
  • Медленный, наш тест показал, что каждый запрос через API Gateway добавляет 100-150 мс задержки.

Решение 2: Kong

профи

  • Масштабируемость, но она должна быть реализована и управляться с нашей стороны.
  • Поддержка SSL и пользовательских доменов.
  • Авторитарные через плагины, с уже упакованными решениями для JWT и OAUTH2.
  • RESTful API для простой интеграции с нашим сервером аутентификации.
  • Расширяемость, если нам нужна какая-то пользовательская логика.
  • Быстрый, наш тест показал, что каждый запрос через Kong добавил задержку 20-30 мс.

против

  • Требуется управление на нашей стороне (обновления, развертывание, обслуживание).
  • Для достижения HA требуется дополнительная конечная точка в виде балансировщика нагрузки для маршрутизации трафика на фактические GW (ы).

Реализация

Мы решили пойти с Конгом.
Основная проблема с размещенным решением заключалась в невозможности маршрутизации трафика в нашу частную сеть, где мы также размещаем частную зону DNS.
Кроме того, расширяемая природа Kong позволила нам создать настраиваемые плагины с логикой, которая имеет отношение к нашим решениям.
Мы работаем с consumer с JWT для отдельного клиента.

Сервер аутентификации отвечает с помощью JWT. Клиент запрашивает доступ из API с помощью JWT, трафик маршрутируется через Kong. Конг проверяет JWT и направляет запрос на микросервис с информацией о потребителе. Служба Micro отвечает клиенту.

Другое

  • Отмена доступа пользователя так же просто, как удаление токена.
  • В запросах JWT не хранится конфиденциальная информация.
  • Все службы знают друг о друге через частную зону DNS .

Схема:

Kong Gateway Schema