microservices - 使用 API-Gateway 时如何处理原始 API

Question

我想知道在使用 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 并且不使用 kong url（端口 8000）时，他/她仍然可以使用 api。

所以我的问题是关于策略以及如何处理原始 api？怎么可能得到保障。我们是否也要在 api 上实现 keycloak 请求？但是 kong 的好处在哪里呢？

标签： microserviceskeycloakapi-designapi-gatewaykong

Answer 1

您的 API 网关为您提供了一个单一入口点，可简化客户端应用程序访问您的服务的方式。您可以在网关上而不是在后面的服务上添加 keycloak 安全性 - 也许如果您有一个设置，您可以阻止客户端对除网关之外的任何服务的网络访问。但即便如此，您可能仍然需要网关和密钥斗篷在后面的服务上。

您可能将 keycloak 放在后面的服务上的原因是因为它们可能需要知道发出请求的用户的身份。如果他们无论如何都要读取令牌，那么向他们添加 keycloak 可能是最直接的。而且您仍然希望网关能够简化客户的生活。然后，您还希望网关将令牌转发到网关后面的服务。（我们在 Activiti Cloud 项目中使用 keycloak 和 spring 云网关，这基本上是我们决定使用 keycloak 保护服务本身并让网关将令牌转发给它们的方式。）