Не разрешать прямые вызовы Microservices. Разрешить только через API-шлюз

Возможно, это странный вопрос (я новичок в Microservices). Но я ищу информацию о том, как это сделать. Не обязательно быть Spring конкретным, но тем, что я использую в данный момент.

Пример: Допустим, у нас есть два Microservices

a) http://myurlfortesting.com:8085/api/rest/serviceone

b) http://myurlfortesting.com:8090/api/rest/servicetwo

и мы установили Spring Zuul (действующий как шлюз API) со следующими правилами, которые пересылают входящие вызовы:

/rest/one → http://myurlfortesting.com:8085/api/rest/serviceone

/rest/two → http://myurlfortesting.com:8090/api/rest/servicetwo

Вопрос... Есть ли способ запретить пользователям напрямую обращаться к службам, упомянутым в и B (разрешать только те, которые входят через шлюз API)?

Можно ли это сделать с помощью Springs Zuul (действуя как шлюз API), настроив некоторые дополнительные фильтры или мы настроим его в конечных точках Microservices?

Было бы даже интересно узнать, есть ли способ не обрабатывать прямые вызовы конечных точек Microservices, которые не поступают через шлюз API.

Может быть, это решено с помощью конкретных правил сервера и не имеет ничего общего с Spring?

Большое спасибо,

/Д

Ответ 1

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

Если вы хотите избежать маршрутизации брандмауэра, вы можете заставить конечные точки проверять определенный HTTP-заголовок или что-то, что задано Zuul перед отправкой запроса, но это было бы взломано и легко обойти. Основываясь на моем прошлом опыте, "правильным" способом было бы сделать это через брандмауэр. Ваше приложение должно отвечать за запросы. Ваш брандмауэр должен нести ответственность за решение, кто может ударить по конкретным конечным точкам.

Ответ 2

Как правило, такую ситуацию обрабатывают путем реализации надлежащего сервера OAuth, в котором только ваш шлюз API будет обрабатывать проверку маркера. Любой прямой вызов микросервиса не будет иметь надлежащего обмена токенами и, следовательно, запросы будут прерваны.

В случае, если вы развернули свои микросервисы на любом облаке, тогда вы можете добиться этого, разоблачая маршруты только для шлюза API. И да, блокировка брандмауэра, переключение IP-адресов - вот некоторые из других способов ограничения доступа к вашим микросервисам.

Ответ 3

Используйте обратный прокси. Мы используем Nginx для той же цели. Шлюзы Api всегда должны быть развернуты за балансировщиком нагрузки для производственных сценариев, чтобы шлюз не был единственной точкой отказа. Кроме того, шлюз и службы развернуты в VPC.

Ответ 4

Мы используем jHipster-Gateway для этой же цели:

Посмотрите ЗДЕСЬ для более подробной архитектуры.

Ответ 5

Правильный способ сделать это с помощью AWS API Gateway будет с недавно запущенной интеграцией VPC Link, которая обеспечивает соединение между шлюзом API и вашим внутренним интерфейсом внутри вашего VPC.

https://aws.amazon.com/about-aws/whats-new/2017/11/amazon-api-gateway-supports-endpoint-integrations-with-private-vpcs/