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

问题描述

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

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

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

我的一些问题是：

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

其他一些可能有用的注意事项：

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

解决方法

这里有很多东西需要解压，答案是：视情况而定

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

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