微服务有很多优点,包括独立的拓展、隔离的业务逻辑、独立的生命周期管理以及简易的分布式开发。这些优点同时也带来了一些弊端,例如微服务可能会增加安全漏洞,因为每个微服务都可以是攻击目标,这无形间增加了攻击面。如果入侵者进入网络,它们可以肆意地攻击单个微服务,因此仅保护网络边界(network border)是不够的,还必须保护网络内部,这就是零信任(Zero Trust)的来源。

零信任的概念由 John Kindervag 提出,它指的是无论网络范围是内部的还是外部的,都不能有任何隐式信任(implicitly trust),任何来源都需要显式验证,并使用最小特权来限制对资源的访问。简而言之,零信任策略就是不相信任何人。除非网络明确知道接入者的身份,否则任谁都别想进入。无论是 IP 地址、主机等等,只要不知道用户身份或者不清楚授权途径的,统统不放进来。

本文展示了将 Istio 服务网络配置为零信任网络的具体步骤,主要使用一个简单的微服务架构,然后通过 Istio 删除隐式的服务到服务(service-to-service)信任关系。

使用自行开发的解决方案保护微服务网络可能非常困难,但服务网格(如 Istio)可以提供帮助,它确保了南北流量(north-south traffic)和东西流量(east-west traffic)的安全。南北流量是进入和离开服务网格的流量,东西流量是网格内的流量,通常是服务到服务的流量。Istio 通过入口(ingress)和出口(egress)网关处理南北流量,流量路由则是由虚拟服务管理。Istio 的 Envoy Proxy 可以管理东西流量,在服务的 Kubernetes Pod 中作为边车(Sidecar)运行。下面我们就看一下这些概念在小型服务网格中的示例。

在服务网格外公开服务

在该例子中,我们将从两个微服务开始:一个在 NGINX Web 服务器中运行的 Web 客户端和一个 Java/Spring Boot 后端的 REST Service。

该客户是个“友好”客户,我们允许其访问后端服务。后面我们将向网格添加一个微服务,一个恶意的“敌人”Web 客户端,该客户端将被拒绝访问后端微服务。后端微服务称为“Capitol-Info”,具有查询和插入 Capitol 数据库的功能。这些微服务公开的 endpoint 如下图所示,该图显示了开放的、不受保护的服务网格体系结构。

在 Istio 服务网格中运行的 Capitol-Client 微服务和 Capitol-Info 微服务

我们现在在尝试保护服务网格的微服务,所以不调用客户端网站到后端微服务。相反,我们要创建一个 API 网格,并允许该网关调用服务,从而实现服务到服务的调用。NGINX 在 Web 客户端的 /capitolservice 路径下提供了一个 API 网关。当使用此路径调用 Web 客户端时,NGINX 网关会将代理 Capitol-Info 服务的调用。对于 Istio 配置,我们首先为客户端和数据微服务(Data Microservices)提供入口网关和虚拟服务。入口网关是标准 80 端口(Web)网关,我们将重点放在 Istio Virtual Service 处理流量路由。我们从以下虚拟服务定义中所示的 Capitol-Info 服务开始:

Capitol Service VirtualService 定义

Capitol-Info 虚拟服务表明,我们仅开放了入站流量(inbound traffic)的 getCapitol REST 操作,没有开放 addCapitol REST 操作的 insert 功能。因此,addCapitol REST 操作不受外部(南北)调用的保护,也不受服务网格内其他微服务调用(东西调用)的保护。这样,getCapitol 调用对南北和东西的调用是开放的。