服务网格在微服务应用中的应用

Question

前提：

• A和B两项服务

• 资源X有所有者U，由服务B管理。

现在，我需要处理这些情况：

1-最终用户需要直接使用服务B的API访问X

2-服务A需要访问X，因为最终用户调用了A(即委托)

3-作为异步通信(例如作业或事件)的一部分，服务A需要访问X (不涉及最终用户)。

我已经研究了很多(一个月了)，但仍然感到困惑。例如，我已经看过oauth/jwt与Kong的集成，但尚不清楚上面第3条如何适合。Istio看起来很理想，因为它可以将身份分配给服务。

如果我和Istio一起去：

• 申请的哪一部分(包括A和B)将负责？

• 最终的(HTTP)请求将使其与应用程序的外观大致类似？

Answer 1

您查看的选项使用JWT令牌进行授权(至少在大多数情况下)。令牌拥有任何一个服务进行决策所需的所有标识和角色信息。它作为bearer令牌在Authorization头中传递。令牌本身是签名的，这样最终用户就不能黑它来获得更多的特权，并且它有一个超时，所以您可以定期地将它们过期。

这意味着，如果一个web服务需要将标识委托给另一个服务，它只需要将令牌嵌入到它提出的请求中。这也意味着它是一种可以生存于API代理委托的身份验证形式。

在最后一种情况下，您可以使用k8s秘密提供身份验证令牌，并让作业协商会话令牌以执行其职责。希望您正在积极地识别和验证访问您的系统的所有代码的标识。在我管理的系统中，异步作业必须像其他客户端一样协商它们的JWT令牌：

• 交换系统标识令牌，这样我就可以验证调用者是否允许与我的服务交互，并且我可以在我的审计日志中肯定地识别它们。
• 调用微服务时使用会话令牌
• 将会话令牌作为消息中的值传递，以便确保消息也来自授权源。

Answer 2

我不确定我的方法是否非常安全，但我使用的是身份验证服务器，这意味着所有请求都带有JWT(授权头，如前所述)。每个接收请求的服务都询问身份验证服务器(http调用)令牌是否正常，如果是，它将响应请求。

服务可以生成它们自己的令牌，但是要确保它们过期，因为如果您不这样做，它们就会永远被破坏，因为它们会被破坏。

事件是如何被授权的。我想这取决于你正在使用的工具。F.e.https://developer.ibm.com/technologies/messaging/tutorials/kafka-authn-authz/。

在任何情况下，如果您的服务只是在防火墙后面，您可能想考虑不使用服务身份验证来服务通信。因此，基本上您可以在部署域中解决这个问题;)。

Answer 3

Oauth与JWT一起为客户服务。但在内部，我需要的是给每个服务一个身份的方法。

SPIFFE就是为此目的而存在的，它是通过服务网格(例如，在Kubernetes上使用mTLS)实现的。