Что делать с оригинальным API при использовании API-шлюза - PullRequest
0 голосов
/ 07 ноября 2018

Мне интересно, что делать с конечной точкой API при использовании шлюза API. Например, когда вы следуете руководству здесь: https://wiredcraft.com/blog/securing-components-in-a-microservice-context

Вы используете keycloak и kong (api-gateway) для защиты API. С помощью kong вы получаете новую конечную точку под http://localhost:8000/data., но «оригинальный» экспресс-сервер все еще прослушивает http://localhost:3001/data.

Это означает, что когда пользователь / злоумышленник знает URL-адрес службы «оригинал» и не использует URL-адрес kong (порт 8000), он / она может работать с API.

Итак, мой вопрос о стратегии и что делать с оригинальным API? Как это могло быть обеспечено. Должны ли мы реализовать запрос keycloak на API? Но в чем же тогда польза от Конга?

1 Ответ

0 голосов
/ 07 ноября 2018

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

Причиной того, что вы можете поставить keycloak на службы, является то, что им, вероятно, потребуется знать личность пользователя, выполняющего запрос. Если они все равно будут читать токен, то было бы проще всего добавить к ним ключи. И вы все еще хотите, чтобы шлюз упростил жизнь для клиентов. Затем вы также хотели бы, чтобы шлюз направил токен службам за шлюзом. (Мы используем keycloak и spring cloud gateway в проекте Activiti Cloud, и именно поэтому мы решили защитить сами сервисы с помощью keycloak и сделать так, чтобы шлюз передавал им токен.)

...