Istio是目前最受关注的服务网格之一,越来越多的公司开始落地Service Mesh架构,并将已有的系统接入Service Mesh。同时随着零信任网络的发展,东西向,南北向流量都需要提供足够的安全保护,因为Istio自身提供了多种安全特性,所以也出现不少基于Istio的零信任架构。在安全中通常关注的重点是南北流量,而我们应该认识到,在云原生的环境下,东西流量安全也应该受到足够的重视。
在Istio默认的配置中,其在集群内暴露了许多未授权和明文传输的服务。通常情况下,这会引起攻击者的注意,当恶意攻击者进入被控制的容器或发现SSRF漏洞后,往往可以利用这些自身的服务扩大攻击范围。

Istio 架构

Istio是一个完全开源的服务网格,它可以作为透明的一层接入到现有的分布式应用程序里。它也是一个平台,拥有可以集成任何日志、遥测和策略系统的API接口。Istio多样化的特性可以帮助我们成功且高效地运行分布式微服务架构,并提供保护、连接和监控微服务的统一方法。同时Istio的安全特性解放了开发人员,使其只需要专注于应用程序级别的安全。Istio提供了底层的安全通信通道,并为大规模的服务通信管理认证、授权和加密。
在1.5版本时Istio进行了一次大的变更,由原来的微服务架构转变成了单体架构。在之前版本其由Pilot、Citadel、Galley等多个微服务组成,现在只需要一个istiod的单体服务。

数据面(Data Plane)

数据面负责数据的转发,一般我们常见的通用网关,Web Server,比如Nginx、Traefik都可以认为是数据面的一种。在Service Mesh的开源世界中,Envoy可以说是最知名的数据面了。Istio使用了Envoy来处理集群中服务之间以及从服务到外部服务的进出流量。它简化并增强了微服务之间通过基础平台提供的网络交互。
另外数据面并非局限于网关类产品,实际上某些RPC框架也可以充当数据面,比如gRPC就已经支持完整的xDS,其也可以当作数据面使用。需要知道的是,一般我们会把负责数据转发的数据面也称为Sidecar。

控制面(Control Plane)

通过xDS协议对数据面进行配置下发,以控制数据面的行为,比如路由转发、负载均衡、服务治理等配置下发。
最新版本的Istio控制面由以下几个组件组成。

  • Pilot:Istio控制面中最核心的模块,负责运行时配置下发,具体来说,就是和Envoy之间基于xDS协议进行的各种Envoy配置信息的推送,包括服务发现、路由发现、集群发现、监听器发现等。
  • Citadel:负责证书的分发和轮换,使Sidecar代理两端实现双向TLS认证、访问授权等。
  • Galley:配置信息的格式和正确性校验,将配置信息提供给Pilot使用。

数据面风险

istio数据平面的核心是proxy,其以Sidecar模式运行,每个服务pod启动时伴随启动istio-init和proxy容器。其中proxy容器对内外开放了许多端口用于监控以及运维。

其会使用的全部服务端口信息如下:

Telemetry & Health 服务

Telemetry服务端口为15090,用于对外提供Envoy的性能统计指标。

Health Check服务如下:

Debug 服务

15000端口提供了Envoy admin API,该端口绑定在本地环回地址上,只能在Pod内访问。当攻击者控制了某容器,即可请求该服务来获取敏感信息。

控制面风险

其会使用的全部服务端口信息如下:

XDS 服务

xDS协议是Envoy获取配置信息的传输协议,也是Istio与Envoy连接的桥梁。Istio控制面的XDS服务提供了各种类型的服务发现能力。需要了解的是,在Istio中XDS和CA服务一起通过端口15010和15012暴露,其中15010提供明文传输,而15012提供了TLS支持。由于端口15010对外暴露了非TLS的XDS服务,那么在集群内意味着我们就可以通过请求控制面的该明文的服务来获取敏感的信息。

对此,我们可以在istiod配置中增加--grpcAddr=""来禁用该端口。

Debug 服务

在istiod即Istio的控制面中同时也提供了Debug服务,这是我们在这些服务中应该注意的重点,它在默认情况下开启,其中端口15014(Control plane monitoring)和端口8080(Debug interface)提供了该服务。通过该服务我们可以获取到集群内的各种信息。
比如在我们在配置某些服务的AuthorizationPolicy,为其提供某种授权验证方式后。
我们可以通过Pilot debug API轻松获取到其配置信息,从而利用这些信息通过授权验证。这是东西向流量中很大的安全隐患,如果使用了Istio,那么请最好排查该功能的存在可能造成的影响。

对此,我们可以在istiod中设置环境变量ENABLE_DEBUG_ON_HTTP=false来关闭该服务。不过需要注意的是,istioctl中的许多命令都依赖于这个接口,这意味着它会普遍存在,我们也更应该关注它的安全风险。

[20210518-更新] 针对此问题,Istio官方将在Istio 1.10版本增加Secured Istio Debug Interface来使istiod的debug信息通过安全的接口获取。istioctl experimental internal-debug 这样可以防止直接设置环境变量关闭debug造成的debug所有功能都不可用的情况。设计文档可见 Secured Istio Debug Interface

总结

在云原生的环境下,东西流量安全应该得到足够的重视,而随着越来越多自动化运维工具的介入,也会对信息监控、采集的安全性,运维与生产网络之间的安全隔离提出更高的要求。
本文简要描述了在Istio的默认配置中,其在集群内暴露的许多未授权和明文传输的服务。在我与Istio官方反馈此类安全问题后,官方后续更新并完善了Istio的文档,在最佳实践中补充了这些情况和应对方式,本文也是对其内容的一些补充说明和思考。