云原生安全技术基于实现

微隔离实现零信任的云原生

网络微隔离实现零信任
的云原生网络随着企业网络基础设施的日益复杂，尤其是云计算等虚拟化网络应用的普及，这种复杂性超越了传 统网络边界安全的防护方法。基于传统物理、固定边界的网络安全也被证明是不够用的，“数据中心内 部的系统和网络流量
是可信的”这一假设是不正确的。网络边界的安全防护一旦被突破，即使只有一台 机器被攻陷，攻击者也能够在所谓“安全的”数据中心内部横向移动。NIST在 2020 年 8 月，发布了最新的零信任架构 [34]，在零信任安全模型中，会假设环境中随时可 能存在攻击者，不能存在任何的隐形信任，必须不断的分析和评估其资产、网络环境、业务功能等的安 全风险，然后制定相应的防护措施来缓解这些风险。在零信任中，这些防护措施通常要保证尽可能减少 对资源（比如数据、计算资源、应用和服务等）的访问，只允许那些被确定为需要访问的用户和资产访 问，并且对每个访问请求的身份和安全态势进行持续的认证和授权。
微隔离作为实现零信任的关键技术之一，在云原生网络安全建设中，同样起着重要的作用。本章将 重点介绍如何在云原生网络中实现零信任的微隔离系统。

概述

在云原生环境中，尤其是云原生网络安全的建设和规划中，以零信任的架构和思路，实现云原生网 络的微隔离和访问控制是必要的。

什么是微隔离

微隔离（Micro-Segmentation）最早是 VMware 为应对虚拟化隔离技术出来的。 Gartner 更是 从 2016 年开始，连续三年将其列为年度 Top10 的安全技术和项目（Micro-Segmentation and Flow Visibility，微隔离和流量可视化），通过对网络流量的可视化和监控，让运维人员能够详细了解系统内 部网络数据包的流向，进而使微隔离能够更好的设置安全策略。
微隔离，顾名思义就是一种更细粒度的网络隔离技术，其核心能力的诉求也是聚焦在东西向流量， 对传统环境、虚拟化环境、混合云环境、容器环境等东西向流量进行隔离和控制，重点用于阻止攻击者 进入数据中心网络或者云虚拟网络后进行的横向移动。
微隔离有别于传统的基于边界的防火墙隔离技术，微隔离技术通常是采用一种软件定义的方式，其
策略控制中心与策略执行单元是分离的，而且通常具备分布式和自应等特点。策略控制中心是微隔离 系统的核心控制单元，可视化展现内部系统之间以及业务应用之间的网络访问关系，并且能够按照角色、 标签等快速的对需要隔离的工作负载进行分类分组，并且高效灵活的配置工作负载以及业务应用之间的 隔离策略。策略执行单元主要用于网络流量数据的监控以及隔离策略的执行，通常实现为虚拟化设备或 者主机上的 Agent。

云原生为什么需要微隔离

在传统网络，或者虚拟化网络中，已经存在了像 VLAN、VPC 之类的网络隔离技术，但是，这些隔 离技术，更偏向于针对确定性网络，或者是租户网络的隔离。
在云原生环境中，容器或者微服务的生命周期相比较传统网络或者租户网络，变的短了很多，其变 化频率要高很多。微服务之间有着复杂的业务访问关系，尤其是当工作负载数量达到一定规模以后，这 种访问关系将会变得异常的庞大和复杂。因此，在云原生环境中，网络的隔离需求已经不仅仅是物理网 络、租户网络等资源层面的隔离，而是变成了服务之间应用层面的隔离。
因此，就网络隔离而言，一方面需要能够针对业务角色，从业务视角更细粒度的实现微服务之间的 访问隔离；同时，还要针对业务之间的关系，在隔离基础上实现访问控制，从而降低网络攻击在东西向 上的横向移动。另一方面，这种灵活快速的网络状态变化，也带来了全新的隔离和访问控制策略更新的 需求，隔离策略与访问控制策略，需要能够完全自动化的应业务和网络的快速变化，实现快速高效的 部署和生效。

云原生网络组网架构

随着容器技术的不断发展和演进，实现容器间互联的云原生网络架构也在不断的进行优化和完善。 从 Docker 本身的动态端口映射网络模型，到 CNCF的 CNI容器网络接口，再到 Service Mesh + CNI 层 次化的 SDN网络。

端口映射

Docker 自身在网络架构上，默认采用桥接模式，即 Linux网桥模式，创建的每一个 Docker 容器， 都会桥接到这个 docker0 的网桥上，形成一个二层互联的网络。同时还支持 Host 模式、Container 模式、 None 模式的组网，具体组网细节，在《2018 容器安全技术报告》中已有详细介绍，本文将不再赘述。
Docker 在这种组网架构下，容器内的端口通过在主机上进行端口映射，完成相关的通信支持。

容器网络接口

CNI（Container Network Interface）是 Google 和 CoreOS 主导制定的容器网络标准，综合考虑了 灵活性、扩展性、IP 分配、多网卡等因素。CNI旨在为容器平台供网络的标准化。不同的容器编排平 台能够通过相同的接口调用不同的网络组件。这个协议连接了两个组件：容器编排管理系统和网络插件， 具体的事情都是插件来实现的，包括：创建容器网络空间（Network Namespace）、把网络接口（Interface） 放到对应的网络空间、给网络接口分配 IP 等。
目前采用 CNI提供的网络方案一般分为两种，Overlay 组网方案和路由组网方案。
Overlay 组网
以 Flannel、Cilium、Weave 等为代表的容器集群组网架构，默认均采用基于隧道的 Overlay 组网方 案。比如，Flannel 会为每个主机分配一个 Subnet，Pod 从该 Subnet 中分配 IP，这些 IP可在主机间路由， Pod 间无需 NAT和端口映射就可以跨主机通讯。而在跨主机间通信时，会采用 UDP、VxLAN等进行隧 道封装，形成 Overlay 网络。
路由组网
以 Callico 为代表的容器组网架构，并没有使用 Overlay 的方式做报文转发，而是供了一个纯三层 的网络模型。在这种三层通信模型中，每个 Pod 都通过 IP 直接通信。Callico 采用 BGP 路由协议，使 得所有的 Node 和网络设备都记录下全网路由，每个容器所在的主机节点就可以知道集群的路由信息。 整个通信的过程中始终都是根据 BGP 协议进行路由转发，并没有进行封包、解包的过程，这样转发效 率就会快很多。然而这种方式会产生很多无效的路由，同时对网络设备路由规格要求较大。

服务网格

服务网格（Service Mesh）当前在云原生网络中，是一个非常流行的架构方案。与 SDN 类似， Service Mesh 通过逻辑上独立的数据平面和控制平面来实现微服务间网络通信的管理。
但是 Service Mesh 并不能替代 CNI，它需要与 CNI一起提供层次化微服务应用所需要的网络服务。 这就可以看出，Service Mesh 与 SDN还是有着一定的区别，SDN主要解决的是 L1-L4层的数据包转发 问题，而 Service Mesh 则主要是解决 L4/L7 层微服务应用间通信的问题。二者可以通过互补配合的方式，
共同实现云原生网络架构。

云原生网络的微隔离实现技术

前文介绍了常见的容器网络组网架构，什么是微隔离，以及为什么云原生网络建设中需要通过微隔 离来实现应用服务之间的访问控制管理。接下来，本章将介绍几种常见的云原生环境中实现微隔离的技 术。
目前，对于微隔离的技术实现，还没有统一的产品标准，属于比较新的产品形态。在 IaaS 层面的 微隔离机制一般而言有三种形态：基于虚拟化技术（Hypervisor）、基于网络（Overlay、SDN），以及 基于主机代理（Host-Agent），而在容器环境中，则有很大的不同。
首先，容器是非常轻量级的，且一个宿主机中容器数量较多，因而，每个容器上部署一个主机代理 的方式是非常昂贵不实用的。
其次，基于虚拟化技术和基于网络的技术都是在访问的主体和客体间部署网络访问控制策略，区别 只是与 IaaS 系统的对接机制不同。而在容器环境中，已有标准的 CNI组网机制和 Network Policy 网络 访问控制策略，因而可融合为一类。
最后，云原生环境中存在大量的微服务，微隔离应更多关注微服务业务，而非简单容器隔离，如 Service Mesh 架构中的 Sidecar 模式做反向代理的应用微隔离成为新的形态。
下面简单介绍云原生中两种微隔离机制。

基于实现

Network Policy 是 Kubernetes 的一种资源，用来说明一组 Pod 之间是如何被允许互相通信，以及 如何与其它网络 Endpoint 进行通信。Network Policy 使用标签（Label）选择 Pod，并定义选定 Pod 所 允许的通信规则。每个 Pod 的网络流量包含流入（Ingress）和流出（Egress）两个方向。
在默认的情况下，所有的 Pod 之间都是非隔离的，可以完全互相通信，也就是采用了一种黑名单的 通信模式。当为 Pod 定义了 Network Policy 之后，只有 Policy 允许的流量才能与对应的 Pod 进行通信。 通常情况下，为了实现更有效、更精准的隔离效果，会将这种默认的黑名单机制更改为白名单机制，也
就是在 Pod 初始化的时候，就将其 Network Policy 设置为 deny all，然后根据服务间通信的需求，制定 细粒度的 Policy，精确的选择可以通信的网络流量。下面是一个简单的 Network Policy 示例。
CNI针对 Network Policy 只是制定了相应的接口规范，Kubernetes 的 Network Policy 功能也都是由
第三方插件来实现的，因此，通常只有支持 Network Policy 功能的网络插件或者安全插件，才能进行相 应的网络策略配置，比如 Calico、Cilium 等。
各种插件在 Network Policy 的实现上，通常会采用 iptables 的方式，通过在主机上配置一系列的 iptables 规则，来实现不同的隔离策略。但是，随着云原生网络的不断发展，承载业务规模的不断增大， 在主机上构建成千上万的网络规则，会让 iptables 不堪重负，而且还要频繁的更新、生效策略，导致这 种实现方法越来越难以满足大规模复杂网络的隔离需求。
另外一种实现方法，就是采用 eBPF，主要解决的是大规模云原生网络的性能问题。这种实现模式 下，控制平面将相应的隔离策略通过 eBPF 指令作用于对应的网卡，进而控制数据包的通过与阻断。这 是 Cilium网络插件一直主张的技术路线，Calico 在 3.13 版本中，也增加了基于 eBPF 的数据平面模式， 例如，Calico 的 eBPF 数据平面将 eBPF 程序挂载到每个 Calico 的接口以及 Pod 的数据或隧道接口的 tc hook 上，这样就能够及早发现数据包，并通过绕过 iptables 和内核通常进行的其他包处理流程，进而 实现一种快速包处理路径。
####　基于 Sidecar 实现
另外一种微隔离的实现方式，就是采用 Service Mesh 架构中的 Sidecar 方式。Service Mesh（比如 Istio）的流量管理模型通常和 Sidecar 代理（比如 Envoy）一同部署，网格内服务发送和接收的所有流 量都经由 Envoy 代理，这让控制网格内的流量变得异常简单，而且不需要对服务做任何的更改，再配合 网格外部的控制平面，可以很容易的实现微隔离。
Istio 官方供的安全架构 [35]如下所示，图中展示了 Istio 的认证和授权两部分，Istio 的安全机制涉 及诸多组件。控制平面由核心组件 Istiod 供，其中包含密钥及证书颁发机构（ Certificate authority， CA）、认证授权策略、网络配置等；数据平面则由 Envoy 代理、边缘代理（Ingress 和 Egress）组件构成。
Istio 的认证机制借助控制平面 Istiod 内置的 CA模块，实现为服务网格中的服务供签名证书， 同时可将证书分发至数据平面各个服务的 Envoy 代理中，当数据平面的服务间建立通信时，服务旁的 Envoy 代理会拦截请求并采用签名证书和另一端服务的 Envoy 代理进行双向 TLS认证从而建立安全传 输通道，保障了数据安全。
有了身份认证机制作为基础，Istio 还供授权机制 [36]，下图为 Istio 的授权流程。管理员 Administrator 使用 yaml 文件指定 Istio 授权策略并将其部署至 istiod 核心组件中，Istiod 通过 API Server 组件监测授权策略变更，若有更改，则获取新的策略，Istiod 将授权策略下发至服务的 Sidecar 代理，
每个 Sidecar 代理均包含一个授权引擎，在引擎运行时对请求进行授权。

参考资料

绿盟 云原生安全技术报告

友情链接

GB-T 34953.2-2018 信息技术 安全技术匿名