基于服务网格的Web安全，第1部分：介绍

作者：Spiros Psarris

如今，许多组织已经接受了微服务；他们已经抛弃了过去遗留的、单体的应用基础设施，而进入了 API、云原生基础设施和容器化的世界。然而，尽管微服务提供了许多好处，它们也带来了一些独特的挑战，例如：

• 如何发现新的服务和基础设施？
• 如何处理服务间通信？
• 使用基于容器的工作负载的额外问题是什么？

为了解决微服务的挑战，最近有一项创新正在流行起来：服务网格。这是对分布式基础设施的补充：一个独立的层，它添加了与上述挑战相关的各种特性。有了服务网格，微服务架构就可以改进发现性、可观察性和服务到服务的通信。

然而，服务网格并不是万无一失的，安全性仍然是一个始终存在的问题。服务网格能像其他架构一样安全吗？或者更进一步：我们能否利用服务网格的特性，使安全性比其他地方更好？

这个由两部分组成的系列文章将回答这些问题。但首先，我们需要打下一些基础，并理解服务网格要解决的问题。

为什么使用服务网格？

服务网格解决了在大多数现代部署的典型规模下出现的许多通信问题。设想一个具有三个节点 A、B 和 C 的基本应用程序架构。节点 A 将充当前端，它需要来自节点 B（后端）和节点 C（数据库）的数据来完成请求。但是如果节点 B 不可用怎么办？节点 A 是否完全停止服务请求？它在放弃之前重试到 B 的连接需要多长时间？它可以找到 B 的另一个实例来使用吗？如果可以，如何使用？一旦找到 B 的实例，如果 C 似乎不可用，所有这些问题都必须重新回答，该怎么办？所有节点如何在提供客户机请求的同时相互更新其运行状况和工作负载？

如果没有一种固有的方法来处理这些类型的通信障碍，开发人员就不得不将这种逻辑写入他们的应用程序代码中。这就产生了许多问题。

首先，对于两个或三个节点，这种方法可能是可管理的，但是如果是 1000 个节点呢？是 10000 个呢？关于服务通信的一个小的物流问题突然变成了一个非常大的问题，应用程序和业务逻辑不应该处理这个问题。

其次，顾名思义，微服务应该很小。将通信逻辑捆绑到它们中会使它们变得比需要的更大和（多得多）更复杂。

第三，有许多与直接服务间通信相关的实际问题。例如，微服务可以使用不同的语言，使用不同的框架或框架版本，使用不同的缓存机制编写，它们甚至可能不使用相同的通信协议。存在许多不兼容的机会。

其次，这种架构可能会造成管理噩梦。当每个微服务都有自己的服务间通信实现时，管理员几乎不可能为重试、超时和断路、故障转移等设置全局策略。

其次是可观察性——这是一个非常严峻的挑战，与上述所有问题都有关。如果出现了问题，但通信逻辑是内置在服务本身中的，那么很难判断问题的原因，以及如何防止问题再次发生。

最后，安全问题也是一个严重的问题——也许是最严重的问题。如果每个微服务都可以接受来自外部世界的传入连接，那么它还需要能够检测和阻止传入流量流中的威胁。这给开发人员带来了巨大的负担，他们不能再仅仅关注业务逻辑；相反，他们必须在一个复杂且不断演变的威胁环境中保持最新状态，以便包括有效的对策，在这个环境中，攻击者不断改进他们的工具和能力。他们还必须为他们创建的每个微服务实现完整和健壮的身份验证和授权功能。随着时间的推移，他们必须保持所有的安全逻辑都是最新的。

显然，期望开发人员在任何时候都能完美地完成所有这些工作是不公平的。大多数微服务可能至少在某些时候会有严重的漏洞，而在今天的互联网上，这种级别的风险是不可接受的。

到目前为止，对于微服务来说，有很多坏消息。幸运的是，有一种方法可以解决所有这些挑战。

进入服务网格

服务网格是通信基础设施的一个附加层，它解决了上面描述的问题，同时也提供了一些额外的好处。

如果没有一个服务网格，一组微服务可以被认为是一个单一的层。它们都直接相互交流。

使用服务网格，服务之间不直接通信。相反，每个服务都有一个代理，部署为一个边车（也就是说，它运行在一个单独的进程中）。在此架构中，服务仅与它们的代理通信，并通过代理进行通信。所有传入的请求（无论是来自其他代理还是外部世界）都被发送到代理，由代理将它们转发给微服务。类似地，所有传出的通信都被发送到代理，然后代理将其路由到适当的目的地。

服务网格创建了一个单独的元通信层。节点和服务通过它们的网格代理传输状态数据和其他关于它们自己的信息，该代理将这些数据传输到堆栈中的其他代理。

应对挑战

一个功能齐全的服务网格可以解决前面列出的所有问题。

• 开发人员不再需要为发现新基础设施、现有基础设施的运行状况监视、故障转移等网络操作编写代码。这都是由服务网格自动完成的，代理彼此通信。

• 开发者不再需要处理他们的微服务运行的网络规模。每个微服务只与其代理通信。

• 每个微服务都是小而精的；它只包含其业务逻辑，不需要其他任何东西。

• 语言和框架可以根据开发人员的喜好来选择。一个现代的网格代理，如 Envoy 支持各种各样的语言和框架。

• 服务间通信由代理自动加固，无论它需要在哪程度。

• 管理大大简化了。管理员不需要尝试通过捆绑到各种不同微服务中的功能来控制网络操作；相反，它们只是管理网格，它被设计成易于配置和管理。

• 管理员可以访问性能指标和其他数据，从代理获得特定段的运行状况和性能的粒度视图。

• 可观察性和透明度是现代网格代理的关键特征。事实上，Envoy 项目的诞生就是为了实现这个主要目标：“网络应该对应用程序透明。当网络和应用程序出现问题时，应该很容易确定问题的根源。”

• 对于微服务开发人员来说，安全性不再是一个问题，因为每个微服务不再需要考虑过滤传入流量、对用户进行身份验证等问题。每个微服务只与它的代理通信，代理是一个受信任的实体。

显然，最后一点要求所有的安全性“繁重的工作”都在代理内完成。为了让微服务假定所有传入的流量都是良性的，它们的代理必须确保它是良性的。

这是如何实现的？这是一个很大的话题，值得单独写一篇文章。

在第二部分中，我们将深入研究与服务网格相关的安全性；我们将讨论网格架构如何用于流量过滤，以及最近的发展如何使使用该架构时更容易实现健壮的安全性。请继续关注！