保护云中的微服务网络已经变得具有挑战性，具有零信任网络理念的Istio服务网格提供了一个解决方案。

译者 | 李睿

(资料图片仅供参考)

审校 | 重楼

清一色读者成长计划社群招募，咨询小助手（微信号：CTOjishuzhan）

在构建单片应用程序时，安全性主要是基于外围的。这意味着使用防火墙保护网络边界和访问控制。随着微服务架构的出现，静态和基于网络的边界不再有效。

如今，应用程序是由Kubernetes等容器编排系统部署和管理的，这些系统分布在整个云平台中。零信任网络(ZTN)是跨基于云计算的网络保护数据的一种不同方法。本文将探讨Istio如何利用零信任网络(ZTN)理念帮助保护微服务。

一、什么是零信任网络(ZTN)？

零信任网络(ZTN)是一种不向用户、设备和服务授予隐式信任的安全范式，并持续验证其身份和访问资源的授权。

在微服务架构中，如果一个服务(服务器)接收到来自另一个服务(客户端)的请求，服务器不应该假设客户端的可信度。服务器应该首先连续地对客户端进行身份验证和授权，然后允许安全地进行通信(参见图A)。

图A：零信任网络(ZTN)环境，在多云的微服务之间强制执行连续身份验证和授权

二、为什么零信任网络环境对于微服务来说是不可避免的？

在分布式服务网络中保护网络和数据的重要性再怎么强调也不为过。以下是面临的一些挑战，指出了微服务需要零信任网络(ZTN)环境的原因：

（1）缺乏网络所有权：应用程序从基于外围的移动到具有微服务的多个云平台和数据中心。因此，网络也变得分散，为网络入侵者提供了更多的攻击面。

（2）网络和安全漏洞增加：自从应用程序迁移到公共云以来，云计算提供商之间的数据和安全漏洞越来越普遍。2022年，近一半的数据泄露事件发生在云端。

（3）管理多集群网络策略已经变得乏味：企业在多个Kubernetes集群和环境中部署数百个服务。网络策略是集群的本地策略，通常不适用于多个集群。他们需要大量的定制和开发来定义和实现多集群和多云流量中的安全性和路由策略。因此，为每个服务配置和管理一致的网络策略和防火墙规则成为一个持久而令人沮丧的过程。

（4）在Kubernetes中，服务到服务的连接本质上并不安全：在默认情况下，一个服务可以与集群内的另一个服务通信。因此，如果一个服务pod被黑客攻击，网络攻击者可以快速轻松地攻击该集群中的其他服务(也称为向量攻击)。Kubernetes不为pod或服务之间的通信提供开箱即用的加密或身份验证。尽管Kubernetes提供了额外的安全特性，例如启用mTLS，但这是一个复杂的过程，必须为每个服务手动实现。

（5）缺乏对网络流量的可见性：如果存在安全漏洞，运维和SRE团队应该能够更快地对事件做出反应。跨环境的网络流量实时可见性差成为SRE团队及时诊断问题的瓶颈。这阻碍了他们的事件响应能力，从而导致较高的平均恢复时间(MTTR)和灾难性的安全风险。

从理论上来说，零信任网络(ZTN)理念解决了上述所有挑战。在实践中，Istio服务网格可以帮助运维团队和SRE团队实现跨云的零信任网络(ZTN)和安全微服务。

三、Istio服务网格如何为微服务启用零信任网络(ZTN)

Istio是一款流行的开源服务网格实现软件，它提供了一种管理和保护微服务之间通信的方法。Istio将网络抽象为一个专用的基础设施层，并提供对微服务之间所有通信的可见性和控制。

Istio的工作方式是在网格中的每个服务旁边注入一个Envoy代理（一个小型Sidecar守护进程）（参见图B）。Envoy是一个L4和L7代理，分别有助于确保微服务之间的安全连接和网络连接。Istio控制平台允许用户管理所有这些Envoy代理，例如直接定义、级联安全和网络策略。

图B：Istio使用Envoy代理来确保集群和云平台之间的服务连接

Istio简化了跨云平台为微服务实施零信任网络(ZTN)环境的过程。受到Gartner公司的零信任网络访问的启发，概述了可以使用Istio实现零信任网络的四个支柱。

Istio服务网格实现零信任网络的四大支柱

1.使用Istio强制身份验证

安全团队需要为每个服务创建身份验证逻辑，以验证发送请求的用户(人或机器)的身份。这个过程对于确保用户的可信度是必要的。

在Istio中，它可以通过使用Peer Authentication和Request Authentication自定义资源（CRD）配置对等和请求认证策略来实现：

（1）对等身份验证策略涉及使用mTLS对服务到服务通信进行身份验证。也就是说，为客户端和服务器颁发证书以验证彼此的身份。

下面是一个PeerAuthentication资源示例，它对foo命名空间中的所有工作负载强制严格的mTLS身份验证：

YAML

1 apiVersion: security.istio.io/v1beta12 kind: PeerAuthentication3 metadata:4  name: default5  namespace: foo6 spec:7 mtls:8 mode: STRICT

（2）请求身份验证策略涉及服务器确保是否允许客户端发出请求。在这里，客户端将把JWT (JSON Web Token)附加到服务器端身份验证请求。

下面是在foo命名空间中创建的RequestAuthentication策略示例。它指定对my-app服务的传入请求必须包含JWT，该JWT由jwtRules中提到的实体使用公钥进行发布和验证。

YAML

1 apiVersion: security.istio.io/v1beta12 kind: RequestAuthentication3 metadata:4 name: jwt-example5 namespace: foo6 spec:7 selector:8  matchLabels:9  app: my-app10 jwtRules:11- issuer: "https://issuer.example.com"12  jwksUri: "https://issuer.example.com/keys"

这两个身份验证策略都存储在Istio配置存储中。

2.使用Istio实现授权

授权是验证是否允许通过身份验证的用户访问服务器(访问控制)并执行特定的操作。持续授权可以防止恶意用户访问业务，从而确保其安全性和完整性。

Authorization Policy是另一个Istio CRD，它为部署在网格中的服务提供访问控制。它有助于创建拒绝、允许策略，并针对入站请求执行自定义操作。Istio允许设置具有不同操作的多个策略，以实现对工作负载的细粒度访问控制。

以下Authorization Policy拒绝从dev命名空间中的工作负载到foo命名空间中工作负载的POST请求。

YAML

1 apiVersion: security.istio.io/v1beta12 kind: AuthorizationPolicy3 metadata:4 name: httpbin5 namespace: foo6 spec:7  action: DENY8  rules:9  - from:10  - source:11    namespaces: ["dev"]12   to:13  - operation:14   methods: ["POST"]

3.Istio的多集群和多云可见性

零信任网络(ZTN)的另一个重要支柱是网络和服务可见性。SRE团队和运维团队需要实时监控跨云平台和集群边界的微服务之间的流量。深入了解网络将有助于SRE团队快速识别异常的根本原因，制定解决方案并恢复应用程序。

Istio通过从数据和控制平台的网格中收集以下遥测数据，提供对通信流和应用程序运行状况的可见性。

（1）日志：Istio收集各种日志，例如服务日志、API日志、访问日志、网关日志等，这将有助于理解应用程序的行为。日志还有助于更快地排除故障和诊断网络事件。

（2）指标：它们有助于了解服务的实时性能，以识别异常并在运行时对其进行微调。Istio除了4个黄金指标(错误率、流量、延迟和饱和度)之外，还提供了许多指标。

（3）分布式跟踪：它是在网格中对流经多个服务的请求进行跟踪和可视化。分布式跟踪有助于理解微服务之间的交互，并提供网格中服务到服务通信的整体视图。

4.使用Istio进行网络审计

审计是分析一个过程在一段时间内的日志，其目的是优化整个过程。审计日志为审计人员提供了对网络活动的有价值的见解，包括每次访问的详细信息、使用的方法、流量模式等。这些信息对于理解数据中心和公共云内外的通信过程非常有用。

Istio提供了关于谁访问(或请求)、何时访问以及访问什么资源的信息，这对于审计人员调查错误情况非常重要。审计人员需要这些信息来建议改进网络整体性能和云原生应用程序安全性的步骤。

四、部署Istio以获得更好的安全态势

在微服务架构中，保护网络和数据的挑战将变得越来越复杂。网络攻击者总是在SRE团队中的任何人有时间注意到漏洞之前抢先发现并利用它们。

实现零信任网络将提供可见性和保护Kubernetes集群免受内部或外部威胁。Istio服务网格可以通过开箱即用实现零信任的能力，从前端引领这项工作。

原文链接：https://dzone.com/articles/zero-trust-network-for-microservices-with-istio-1

标签：