Service Mesh对企业安全而言意味着什么？

你听说过Service Mesh（服务网格）吗？

我相信你听说过。Service Mesh正成为容器生态圈愈发重要的一部分。

本文将简要概述Service Mesh的作用，并深入探讨它们对于企业安全性的意义。

Service Meshes是什么？它为何如此重要？

连接问题

要想理解Service Mesh的存在原因，首先考虑一下容器环境中的网络连接。

想象一下当你运行一个云原生应用时会发生什么。但凡它具有一定的规模和复杂性，它通常都需要由大量单独的服务组成，这些服务间为了能够像一个单体桌面应用程序组件一样高效地运行，需要相互进行协调。

再加上在任何指定时间运行的每个服务的实例数量，以及这些实例的状态及可用性的变化，不难看出，简单的将一个服务连接到另一个服务的行为，在这样的情形下会变成多么恐怖的组合问题。

编排是基础

多亏了有Kubernetes等编排工具，云原生应用程序不会出现混乱或者从内部logjams出现冻结，它们将服务和实例组织成方便管理和寻址的单元，这样就可以通过系统化的方式找到并访问这些单元。

这些编排工具就好像一个房屋开发商，他们铺设街道，在新的社区建造房屋——它们建立了框架和交通线路，然而大多数情况下，处理社区的交通细节并不是它们的工作。

管理流量

这就是需要Service Mesh的地方。当一个服务需要向另一个服务发送请求时，Service Mesh提供了一个标准化的接口，允许请求发送，并且管理这一个过程。

Service Mesh（如lstio和Linknerd）通常充当微服务之间的请求和其他流量的代理，负责服务发现和执行各种相关任务，包括入口、出口、负载均衡和故障处理。当它接收到服务请求时，它会找到一个服务的可用实例，这个实例需满足一组可配置的规则以及在请求服务和目标服务之间的路由流量。

接手复杂的工作

这意味着你可以将服务发现和与其关联的大多数任务从应用程序设计和代码（以及架构脚本）中移出来，并交给Service Mesh处理它们。请求服务只需要使用目标服务的抽象标识符来提出请求；而Service Mesh将负责剩下的部分。

当然，Service Mesh能够处理的不止这些，还包括了跟踪、度量、加密、认证以及其他与性能和安全相关的任务。lstio和linkerd可以一同使用，把两者包中最强大的特性集成在一起，进行微服务相关的流量管理优化。

Service Mesh与企业安全

上文所说的这一切，对于企业安全意味着什么呢?

Istio和Linkerd等平台的安全性和整体流量管理功能是否能够提供足够的保护？或者恰恰相反，他们是否会暴露出新的攻击面，给入侵者提供了后门攻击的机会？

事实是，任何控制基础设施的新元素都有可能包含这两者。在Service Mesh的情景下，如入口/出口管理、代理和加密等特性将与安全相关的元素添加到系统中。与此同时，这些平台会管理流量和访问，并且受到应用程序和其他基础设施元素的信任，这使得它们成为了攻击目标。

Service Mesh的整体作用是在应用程序的边界（即入口规则）处提供一些强化，并为该周边内的流量创建有效的通道。就企业安全而言，这意味着你需要关注至少两条（或许更多）的潜在攻击路线。

当入侵者突破边界

如果入侵者突破Service Mesh的基本边界防御，并且甚至侵占了一个服务的某一个实例，将会发生什么？如果该服务向Service Mesh发送请求，或它响应Service Mesh的请求，那么恶意负载可能会被注入系统中，从而利用Service Mesh的高效流量管理将负载传递到尽可能多的潜在目标。如果Service Mesh将服务表现出来的样子认定为“信任”，而应用程序又错误地判定Service Mesh在服务之间传递的是非恶意数据，那么任何的恶意参与者都可以利用这种信任，将自己伪装成有效服务。

当然，实际上像Istio和Linkerd这样的平台确实包含了维护安全流量的功能，比如TLC认证；Istio的Role-Based Access Control（基于角色的访问控制，RBAC）提供了灵活、可定制的多级访问控制。但是，如果入侵者突破了这些防御，仍然可以在系统内移动并且造成破坏。

攻击Service Mesh基础设施

Service Mesh平台，就像当下其他任何基于云基础架构的元素一样，是由代码构成的，并且和其他类型的代码一样容易受到攻击。对入侵者来说，最具诱惑力的攻击面可能是控制发现和路由的规则——如果请求可以重新路由到外部位置，那么整个系统都可能会受到危害。

当然也会有其他的攻击点。入口、出口、代理以及负载均衡等功能都可能会出现先前未监测到的切入点。简而言之就是，基础设施的元素越多地控制应用程序和整个系统，那么它就越容易成为攻击的目标，也就越应该关注它。