如何保护 Kong 网关后面的 API 的公共和内部流量

Question

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

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

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

我的一些问题是：

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

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

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

Answer 1

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

\n

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

\n

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

\n