双向TLS：保护服务网格中微服务的通信安全

世界正朝着基于微服务的应用程序发展。服务网格已经成为部署和管理微服务环境的主要架构之一，这是因为它带来了高级流量管理，整体可观察性和更好的安全性。微服务通过API相互通信，因此保护各个服务之间的通信比以往任何时候都变得越来越重要。

双向TLS（mTLS）可确保服务网格中微服务之间的通信安全。它使用加密安全技术相互认证各个微服务并加密它们之间的流量。

为什么要使用mTLS？

根据Google的说法，90％的互联网流量都是经过加密的，以防止窃听和中间人攻击。然而，很多开发人员和组织认为，集群内部的流量是安全的并且不容易受到攻击的，所以今天依然有许多云原生应用程序部署还没有在微服务之间加密通信。微服务之间的通信不仅应得到保护，而且许多开发规范（例如GDPR和HIPAA）也建议采用端到端加密来保护传输中的所有数据。

在这个零信任安全时代，必须对每个微服务通信（请求-响应）进行身份验证，授权和加密。原因如下：

• 身份验证唯一地标识每个微服务，并确保流氓软件无法访问你的敏感数据。
• 授权确定哪些微服务可以相互通信。
• 加密不仅可以防止第三方拦截和查看传输中的数据，还可以阻止中间人攻击。

随着公司向零信任安全性迈进，mTLS提供了一种加密安全的方式来认证，加密和强制执行微服务之间的通信策略。

什么是mTLS？

双向TLS（mTLS）是指在服务器端和客户端之间使用双向加密通道。如今，mTLS是确保云原生应用程序中微服务之间的通信安全的首选协议。

双向认证，顾名思义，客户端和服务器端都需要验证对方的身份，在建立Https连接的过程中，握手的流程比单向认证多了几步。单向认证的过程，客户端从服务器端下载服务器端公钥证书进行验证，然后建立安全通信通道。双向通信流程，客户端除了需要从服务器端下载服务器的公钥证书进行验证外，还需要把客户端的公钥证书上传到服务器端给服务器端进行验证，等双方都认证通过了，才开始建立安全通信通道进行数据传输。

图1：什么是mTLS？

传输层安全性（TLS）已用于保护Internet上客户端和服务器之间的流量很多年，但通常使用单向身份验证-服务器向用户提供证书以证明其身份。这种单向身份验证的基本示例是–在线访问银行帐户时，服务器向你的计算机发送证书，以证明它实际上是你要连接的银行。该证书还包含一个公共加密密钥，该密钥用于在你和数据通过的银行之间创建一个安全的加密链接。

双向TLS扩展了客户端-服务器TLS模型，以包括双方的身份验证。在银行依靠其他特定于应用程序的机制来确认客户身份的情况下，例如用户名和密码（通常带有两因素身份验证），mTLS使用x.509证书来识别和验证每个微服务。每个证书都包含一个公共加密密钥和一个身份，并由受信任的证书颁发机构签名，该证书颁发机构证明该证书代表提出该证书的实体。

在mTLS中，服务网格中的每个微服务都会验证对方的证书，并使用公共密钥来创建每个会话唯一的加密密钥。

mTLS在服务网格中的工作方式

从Citrix那里我们学到的是，在更高层次上，在服务网格中基于mTLS来身份验证和建立加密通道的过程涉及以下步骤：

1. 微服务A发送对微服务B证书的请求。
2. 微服务B回复其证书，并请求微服务A的证书。
3. 微服务A向证书颁发机构检查证书是否属于微服务B。
4. 微服务A将其证书发送到微服务B，并且还共享会话加密密钥（使用微服务B的公共密钥加密）。
5. 微服务B向证书颁发机构检查其收到的证书是否属于微服务A。
6. 通过对两个微服务进行相互认证并创建会话密钥，可以对它们之间的通信进行加密并通过安全链接发送。

服务网格控制平面对mTLS的作用

Istio可能是最著名的，功能丰富且成熟的服务网格控制平面，它可以提供安全的服务到服务通信，而无需更改任何应用程序代码。从mTLS角度来看，Istio和所有服务网格控制平面必须提供：

• 处理证书签名和管理的证书颁发机构。
• 一个API配置服务器，用于将通信策略（例如身份验证策略，授权策略和安全命名信息）分发到代理。

控制平面将证书和授权策略分发到Sidecar。当两个微服务需要通信时，Sidecar会建立一个安全的代理链接，并负责加密通过它的流量。

Sidecar在mTLS中的作用

虽然可以在微服务自身中定义通信安全策略并执行身份验证和加密，但它需要在每个微服务的代码中实现身份验证机制，定义授权策略和流量加密。

这是低效的，因为你必须将它们写入每个微服务中，必须在应用程序更改时对其进行更新，并且需要在每个release版本上对其进行测试，以确保新代码不会有通信异常。这可能给开发人员造成负担，导致人工操作错误并妨碍他们将精力集中在业务逻辑的代码实现上。在服务网格中，确保通信安全的开销被转移到了每个微服务旁边的Envoy等Sidecar代理。

当两个微服务需要通信时，将由Sidecar建立mTLS连接，加密的流量将通过该mTLS连接流动。Sidecar交换证书并通过证书颁发机构相互认证。他们检查控制平面推送的配置中的授权策略，以查看是否允许微服务进行通信。如果是这样，则Sidecar将使用生成的会话密钥建立安全链接，以便微服务之间的所有数据都将被加密。实际的微服务应用程序代码本身不受影响。因此，Sidecar使应用程序开发更加敏捷和高效。

为什么非mTLS通信仍然很重要

有时，微服务会与未启用mTLS或不属于同一mTLS生态系统的外部微服务通信。在这些情况下，必须通过未加密或未认证的通道以纯文本格式发送数据。

还有，微服务可能需要将遥测数据发送到非mTLS监控系统，每个SRE都需要遥测数据以获取对根本原因分析和故障排除的可见性。

此外，随着多集群部署变得越来越流行，非mTLS的数量将会增加，因为某些集群将启用它，而另一些集群将不启用它。

在服务网格中实现mTLS

有许多服务网格控制平面，其成熟度和独特功能各不相同。当涉及到mTLS时，所有服务网格都以相同的原理工作，以保护微服务之间的通信。许多服务网格提供了可靠的mTLS，但是它们的整体功能和部署方式有所不同。你需要了解所选服务网格控制平面如何实现mTLS以及默认情况下实现了哪些功能，否则你就有可能破坏应用程序。

例如，Istio的mTLS实现先进且灵活。它提供了详细级别来定义mTLS部署的范围。可以针对特定服务，在命名空间或整个服务网格上设置双向TLS，显然，Istio为每个服务选择最优的匹配策略。

这个粒度使你可以将名称空间所有权分配给不同的组，并让他们定义自己的mTLS设置。也就是说，每小组都必须注意他们部署的mTLS限制级别，尤其是对于与外部通信的微服务。

当心mTLS默认值：尝试保护应用程序时不要破坏你的应用程序

你应注意默认情况下服务网格如何实现mTLS。Istio支持三种mTLS模式，使你可以控制微服务在服务网格中的通信方式：

1. Permissive(允许)：代理将接受mTLS和纯文本流量。
2. Strict(严格)：代理仅接受mTLS流量。
3. Disable(禁用)：禁用双向TLS。

图2：mTLS部署模式

明智地，默认情况下，Istio将每个代理配置为在Permissive模式下使用mTLS，这允许服务接受纯文本和双向TLS通信。这种灵活性是所有服务网格实现的最佳实践，因为它允许微服务接受来自其他来源的非mTLS流量，从而会破坏应用程序。

Permissive模式可帮助你使用mTLS，从而降低了破坏应用程序的风险，因为你可以逐步部署，测试通信并加强安全性。这在工作负载迁移期间非常有用，因为它允许无法使用双向TLS的微服务移入网格并仍然可以通信。

请注意，Permissive 模式是一个很好的默认设置，但是它实际上削弱了你的安全状态，因为它为与其他来源进行纯文本通信打开了大门。尽管从一开始就严格执行Strict模式的mTLS可能会很诱人，因为它更加安全，但它是一项策略，需要进行仔细的规划，全面的分析。当你选择Strict模式时，有很多事情会破坏应用程序。例如：

• 没有Sidecar的微服务将无法完成mTLS握手；你可能不得不在没有微服务的情况下向这些微服务添加补充功能。
• 服务端口的命名错误将导致Sidecar拒绝mTLS请求；请特别注意Istio的$protocol- $service的命名规范。

各种服务网格中的mTLS差异

当然，Istio并不是唯一提供mTLS来保护通信的服务网格。其他服务网格也提供相似的功能，但有所不同。

红帽OpenShift基于Istio控制平面，并具有类似的mTLS功能，包括默认情况下的细化实现和Permissive模式，还用OpenSSL取代了底层的BoringSSL。

LinkerD还提供mTLS，默认情况下会自动启用该功能，以通过LinkerD代理在网状容器之间进行基于HTTP的通信。尽管LinkerD承认其mTLS产品中存在一些缺陷，但最新的2.9版本解决了其中的一些缺陷，并将mTLS保护扩展到了所有TCP连接-这是向零信任通信迈出的一大步。

在Kuma服务网格中，默认情况下未启用mTLS。启用后，默认情况下会拒绝数据平面代理之间的每个连接。尽管这是值得称赞的安全性，但这确实意味着你必须使用TrafficPermissions功能显示允许连接。就是说，Kuma缺乏Istio提供的安全通信功能的广度，并且Kuma可能需要一些发展。

Amazon Web Services的AWS App Mesh还支持微服务之间的加密。你可以使用AWS Certificate Manager或自带证书。AWS App Mesh支持“strict”和“Permissive”模式。

选择适合你的mTLS

双向TLS是服务安全的重要组成部分，对于保护服务网格中微服务之间的通信至关重要。但是，实施并不简单。你需要意识到，微服务经常与非mTLS实体进行通信，因此你应该相应地留出余地。你应该权衡便利性和安全性来仔细选择通信模式。最后，无论你选择哪种服务网格控制平面，都要注意mTLS的特定实现-因为它们并不完全相同。

译文链接: https://thenewstack.io/mutual-tls-microservices-encryption-for-service-mesh/