Шлюз AWS API с сервисами Kubernetes
Я пытаюсь изучить сервисы AWS, и сейчас он в основном сосредоточен на API Gateway. Я понимаю некоторые преимущества шлюза API, перечисленные ниже.
- Предоставлять службу как конечные точки REST
- Такие функции, как аутентификация и авторизация
- Возможность развертывания нескольких этапов
- Параметры регулирования
Тем не менее я не уверен, сможем ли мы использовать API Gateway Infront для некоторых сервисов Kubernetes, которые мы развернули в EKS. Например, давайте рассмотрим, что эти службы представляют собой некоторые микросервисы при весенней загрузке, которые отвечают на HTTP-запросы и содержат некоторый настраиваемый механизм аутентификации/авторизации с использованием Spring Security.
Действительно ли нам нужна конечная точка шлюза API перед такими сервисами? Также я хотел бы знать, каков стандартный/предпочтительный способ создания инфраструктуры в AWS для таких сервисов.
Ответы 1
Короткий ответ: нет, вам не обязательно, но, вероятно, стоит.
Обычно EKS развертывается в частном VPC, и даже если вы можете сделать его общедоступным другими способами, соединение VPC со шлюзом API и балансировщиком нагрузки сети/приложения, вероятно, является самым безопасным способом.
Представьте себе случай, когда кто-то развертывает небезопасный сервис в EKS. Если вы откроете кластер, вы рискуете столкнуться с проблемами безопасности. Опять же, есть способы защитить кластер Kubernetes и в этих случаях. Это также облегчит использование SSL (в дополнение к уже перечисленной вами функции).
Я бы сказал, что лучше всего в AWS использовать шлюз API для аутентификации и ваши микросервисы в качестве ресурсов, на которых вы проверяете аутентификацию (в Cognito, например).
При этом ваш проект будет зависеть от AWS.
Альтернативой может быть реализация собственного шлюза и безопасности в вашем кластере Kubernetes, что можно сделать с помощью сервисной сетки, такой как Istio или аналогичной.
В любом случае не обеспечивайте безопасность только на уровне служб. Никогда нельзя предполагать, что все услуги будут защищены.
Да, я имею в виду авторизацию в сервисах. Обычно у вас есть JWT или аналогичный запрос, который вам нужно передать службам. Я считаю, что весной установка называется ресурсами. Для JWT вы можете посмотреть docs.spring.io/spring-security/reference/servlet/oauth2/… для справки.
Спасибо большое, Грекиер. Теперь я понимаю, насколько это важно для аутентификации на уровне шлюза API. Не могли бы вы объяснить немного больше ниже. «и ваши микросервисы как ресурсы, на которых вы проверяете аутентификацию (например, в Cognito)». Если безопасность обеспечивается шлюзом API, что нам придется обрабатывать в микросервисе? Вы имеете в виду здесь авторизацию?