3

我们目前有多个不在网关后面的 API。公开的 API 使用 OpenID Connect 进行身份验证和声明授权。一些 API 仅供内部使用，并在防火墙后进行网络保护。

我们计划在我们的 API 前设置 Kong Gateway Enterprise。我们应该能够在网关处集中来自公共客户端的令牌验证。我们也可以集中一些基本的授权（例如范围）。一些逻辑可能仍需要在上游 API 中发生。因此，这些 API 仍然需要知道调用者（客户端和用户）的上下文。

理想情况下，我们希望能够拥有可以公开公开并在内部调用的 API，以避免重复逻辑。我想了解一些在 Kong 上实现这一点的安全方法。我仍然不清楚如何在网关后面设置系统。

我的一些问题是：

  • 我们是否应该同时拥有内部网关和外部网关？是否有关于如何选择何时创建单独网关的指导？
  • 如果我们在一个链中有多个上游服务，你如何传递 auth 上下文？
    • 自定义标题？
    • 传递原始的 JWT？
  • 我们如何使服务安全地响应内部和外部调用？
    • 我们可以设置一个网格并使用 mTLS，但是在 mTLS 和网关之间传递 auth 上下文的方法会不会有所不同？
    • 我们可以从 Kong 设置自定义标头，并让其他内部服务也呈现它们。但是由于这不在 JWT 中，我们不是失去了声明的真实性吗？
    • 我们可以让每个调用者（包括内部服务）获得他们自己的令牌，但这可能会使客户端和机密的数量难以管理。另外，当这些服务仍然代表用户作为早期请求的一部分时，它不会处理这种情况。
    • 或者我们可以继续保持独立的内部和外部服务，但重复一些逻辑。

其他一些可能有用的注释：

  • 除了我们的 OIDC 提供商之外，没有其他现有的 PKI。
  • 服务不会全部被容器化。想想 EC2 上的 IIS。
  • 服务大多是 REST 式的。
4

1 回答 1

2

这里有很多东西要解压，答案是：这取决于

通常，您应该在外部公开最低限度的 API，因此 DMZ 中的单独网关仅具有外部客户端所需的 API 端点。您通常会进行更多内部更改，因此您不想意外暴露敏感端点。

在涉及 API 时不要太担心重复，拥有多个 API 网关是很常见的，甚至是用于外部通信的出口网关。有像（BFF - 前端模式的后端）这样的模式，其中每个客户端都有自己的用于编排、安全、路由、日志记录和审计的网关。彼此隔离的客户端越多，进行 API 更改的风险就越小。关于传播 Auth 上下文，它实际上归结为信任，以及您的网络和内部参与者的安全性。如果您使用的是自定义标题，那么您必须考虑“混淆代理问题”。使用签名的 JWT 可以解决这个问题，但如果令牌泄露，它可能会被恶意用于攻击链中的任何服务。您可以使用 RFC8693 令牌交换来缓解这种情况，甚至可以将其与 MTLS 结合使用，但这对您的应用程序来说可能是多余的。如果 JWT 由外部客户端处理，则风险更大。在这种情况下，理想情况下它应该是不透明的，并且只被面向外部的网关接受。然后，该 GW 可以将其交换为用于所有内部通信的新令牌。

于 2021-05-05T21:53:11.037 回答