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

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

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

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

我有几个问题：

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

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

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

---

这里有很多东西需要打开，答案是：这要看情况而定

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

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