将服务网格视作安全工具（Security）

如果你和大多数安全专家一样，那么很有可能你已经开始对微服务感到些许失望，甚至失望很多。从软件架构师的角度来看，微服务体系结构——也就是利用REST构建一些小型、分布式、模块化组件的体系结构，是非常强大的。

想在不降低整个应用程序性能的情况下快速更改组件，还是想即时添加新功能？微服务实现了这些目标。您可以修改（或添加）您感兴趣的特定服务，而无需重新构建大型单片应用程序。

从安全管理的角度来看，这样做的弊端当然是一场噩梦。有几个原因，对于安全架构师来说，这是一个挑战，因为我们最有效的工具之一 —— 应用程序威胁建模，依赖于从攻击者的角度分析组件之间的交互。

这样做的前提是：随着时间的流逝，通信通道几乎保持不变。如果开发人员每五分钟发布一次更新，并且如果服务之间的路径发生变化，那么威胁模型仅在该时点有效。如果您曾试图威胁模型（并使其保持最新状态）以大量使用微服务，而该应用正在迅速发展，那么您将很确定地知道这钟情况会令人相当沮丧。

捕捉风向

从运营的角度来看，这也是一种挑战。 在后台，最普遍的微服务实现方法是带有Kubernetes编排的Docker。 这意味着实际运行服务的容器被设计为即时的：添加新容器以适应负载增加，并重新部署容器以适应应用程序更改或更新的配置。

为了说明为什么这具有挑战性，让我们假设您几天前接到了入侵检测系统警报，日志条目或可疑活动，具体涉及哪些主机/节点，它们处于什么状态？

试图弄清楚这一点就仿佛是要追赶瞬息万变的风：这些容器可能在您到达那里时就被覆盖并重新部署了几次。 除非警报可以清楚地显示发生了什么（什么时候发生的？），您的事件解决方案现在取决于从过去某个时间起对高度复杂系统的状态进行逆向工程。

幸运的是，最近的一项ish技术可以显著地帮助实现这一点，那就是服务网格体系结构。服务网格作为一种设计模式，实际上可以通过几种方式为安全从业人员提供强大的帮助。它对开发人员而言功能强大，对安全领域中的人员而言也同样强大（甚至更多）。

服务网格如何提供帮助

什么是服务网格？一种可行的方式是把服务网格当作为您服务的“交通调度员”。当一个服务想要与另一个服务通信时，有两个选项可供选择。选项一：它知道存在的所有其他服务并实现与之对话的逻辑。选项二：它要求其他人完成这项工作。

把服务网格想象成寄一封信。如果我想给我在肯塔基州的表弟寄封信，，一种选择是我亲自写这封信，坐上汽车，开车去他家，然后把信放在他手中。这取决于一系列先决条件：我知道他的地址，有一辆车可以随时开走，知道怎么去他家，知道他是否搬家了，等等。只是这样做的效率不高。

一个更好的选择是我写好这封信，填上地址，让邮局来负责送信。让他们维护必要的信息和投递设备，这样我就可以专注于我真正关心的事情：我的信成功到了目的地。

就实现方式而言，有很多方法可以做到这一点，但最常见的方法是通过“sidecar”容器。什么是sidecar容器？它只是另一个容器——运行代理的容器，该代理被专门配置为在服务之间引导应用程序流量。这意味着它的配置和部署方式可以使消息的“传递”与应用程序逻辑分离。

从应用程序开发的角度来看，好处应该是相当明显的：开发人员可以关注业务逻辑，而不是“东西向”通信机制（即服务之间的通信）。不过，从安全角度来看，也有优势。

值得注意的是，它为监视和其他安全服务提供了一个挂钩。 无需调整（或者，事实上，甚至不需要了解）单个服务的应用程序逻辑，就可以添加此功能。 所以，举个例子，如果我想允许服务A使用TLS和可靠的身份验证实现仅与服务B的对话，则可以这样做。同样，如果我想在给定的时间点记录容器与另一个容器的对话版本，则可以将其配置为提醒功能。

集成因素

如果你觉得这很有吸引力，那也是理所当然的。事实上，服务网格代表了安全领域中很少出现的事情：它使开发人员以更安全的方式（而不是较不安全的方式）进行操作的阻力最小。

开发人员发现服务网格很有吸引力，因为他们不必为与其他服务的通信和交付物流的细节操心。此外，服务网格还添加了安全选项，否则开发者不得不在应用程序层强制执行这些选项。

因此，如果您所在的组织正在考虑微服务，那么服务网格体系结构实际上可以帮助维护组织环境。如果已经在使用它，那么了解它的含义可以帮助您将其集成到对话中，并为您提供减轻某些微服务“痛点”的工具。

唯一需要注意的是，在学习新工具集和使体系结构工具适应新模型方面，使用服务网格确实需要一些准备工作。无论你使用的是Istio + Envoy，Linkerd还是其他工具，它首先都应该指引你阅读文档，以了解可用的功能，工具集的工作方式以及可用的策略/配置选项。无论如何，这是一个好的想法，因为验证该配置，只是个早晚的问题。

另外，如果您仍然打算对应用程序进行威胁建模，则可能需要考虑新的范例，这是适应多种情况的好方法。

具体地说，在数据流分析中使用更合乎逻辑的观点帮助性很大——也许可以通过单独分析每个服务的输入和输出，而不是假设“服务A”只与“服务B”对话（或者更糟的是，假设服务之间的静态流量基于应用程序在给定时间点的相应操作。

关键是，安全专业人员不仅不应该害怕服务网格，而且还应该考虑积极接受它的坚实论据。