本博客地址：https://security.blog.csdn.net/article/details/130044619

一、微隔离介绍

1.1、微隔离概念

在主体执行动作时，对主体权限和行为进行判断，最常见的是网络访问控制，也就是零信任网络访问（ZTNA）。零信任网络访问是零信任实现中很重要的技术分支，而微隔离作为实现ZTNA的关键技术之一，在云原生网络安全建设中同样起着重要的作用。

微隔离是一种更细粒度的网络隔离技术，其核心能力的诉求也是聚焦在东西向流量，对传统环境、虚拟化环境、混合云环境、容器环境等东西向流量进行隔离和控制，重点在于阻止当攻击者进入数据中心网络或者云虚拟网络后进行的横向移动。

微隔离有别于传统的基于边界的防火墙隔离技术，微隔离技术通常是采用一种软件定义的方式，其策略控制中心与策略执行单元是分离的，而且通常具备分布式和自适应等特点。

策略控制中心是微隔离系统的核心控制单元，可视化展现内部系统之间以及业务应用之间的网络访问关系，并且能够按照角色、标签等快速地对需要隔离的工作负载进行分类分组，高效灵活地配置工作负载以及业务应用之间的隔离策略。

策略执行单元主要用于网络流量数据的监控以及隔离策略的执行，通常实现为虚拟化设备或者主机上的代理。

1.2、云原生环境中两种网络微隔离的机制

1、基于Network Policy实现

Network Policy是Kubernetes的一种资源，用来说明一组Pod之间是如何被允许互相通信，以及如何与其他网络端点进行通信。Network Policy使用标签选择Pod，并定义选定Pod所允许的通信规则。每个Pod的网络流量包含流入（Ingress）和流出（Egress）两个方向。

在默认的情况下，所有的Pod之间都是非隔离的，完全可以互相通信，也就是采用了一种黑名单的通信模式。当为Pod定义了Network Policy之后，只有允许的流量才能与对应的Pod进行通信。在通常情况下，为了实现更有效、更精准的隔离效果，会将这种默认的黑名单机制更改为白名单机制，也就是在Pod初始化的时候，就将其Network Policy设置为deny all，然后根据服务间通信的需求，制定细粒度的策略，精确地选择可以通信的网络流量。

CNI针对Network Policy只是制定了相应的接口规范，Kubernetes的Network Policy功能也都是由第三方插件来实现的。因此，通常只有支持Network Policy功能的网络插件或者安全插件，才能进行相应的网络策略配置，比如Calico、Cilium等。

2、基于Sidecar实现

微隔离的另外一种实现方式是采用Service Mesh架构中的Sidecar方式。Service Mesh（比如Istio）的流量管理模型通常与Sidecar代理（比如Envoy）一同部署，网格内服务发送和接收的所有流量都经由Sidecar代理，这让控制网格内的流量变得异常简单，而且不需要对服务做任何的更改，再配合网格外部的控制平面，可以很容易地实现微隔离。

二、Cilium介绍

开源地址及说明文档：https://github.com/cilium/cilium

2.1、概念

Cilium是一种开源的云原生网络实现方案，与其他网络方案不同的是，Cilium着重强调了其在网络安全上的优势，可以透明地对Kubernetes等容器管理平台上的应用程序服务之间的网络连接进行安全防护。

Cilium在设计和实现上基于Linux的一种新的内核技术eBPF，可以在Linux内部动态插入强大的安全和可见的网络控制逻辑，相应的安全策略可以在不修改应用程序代码或容器配置的情况下进行应用和更新。其特性主要包括以下三方面：

⬤ 提供Kubernetes中基本的网络互连互通的能力，实现容器集群中包括Pod、Service等在内的基础网络连通功能。
⬤ 依托eBPF，实现Kubernetes中网络的可观测性以及基本的网络隔离、故障排查等安全策略。
⬤ 依托eBPF，突破传统主机防火墙仅支持L3、L4微隔离的限制，支持基于API的网络安全过滤能力。Cilium提供了一种简单而有效的方法来定义和执行基于容器/Pod身份的网络层和应用层（比如HTTP/gRPC/Kafka等）安全策略。

2.2、架构

Cilium位于容器编排系统和Linux Kernel之间，向上可以通过编排平台为容器进行网络以及相应的安全配置，向下可以通过在Linux内核挂载eBPF程序，控制容器网络的转发行为以及安全策略执行。

在Cilium架构中，主要组件包括Cilium Agent和Cilium Operator。

⬤ Cilium Agent作为整个架构中最核心的组件，通过DaemonSet的方式，以特权容器的模式运行在集群的每个主机上。Cilium Agent作为用户空间守护程序，通过插件与容器运行时和容器编排系统进行交互，进而为本机上的容器进行网络以及安全的相关配置。同时提供了开放的API，供其他组件进行调用。

⬤ Cilium Operator主要负责管理集群中的任务，尽可能地保证以集群为单位，而不是单独地以节点为单位进行任务处理，主要包括通过etcd为节点之间同步资源信息、确保Pod的DNS可以被Cilium管理、集群Network Policy的管理和更新等。

Cilium架构如图所示：
在这里插入图片描述

2.3、组网模式

Cilium提供多种组网模式，默认采用基于vxlan的Overlay组网。除此之外，还包括：

⬤ 通过BGP路由的方式，实现集群间Pod的组网和互联；
⬤ 在AWS的ENI（Elastic Network Interface）模式下部署使用Cilium；
⬤ Flannel和Cilium的集成部署；
⬤ 采用基于ipvlan的组网，而不是默认的基于veth；
⬤ Cluster Mesh组网，实现跨多个Kubernetes集群的网络连通和安全性等多种组网模式

2.4、可观测

Cilium提供了网络可视化组件Hubble，Hubble建立在Cilium和eBPF之上，以一种完全透明的方式，提供网络基础设施通信以及应用行为的深度可视化，是一个应用于云原生工作负载、完全分布式的网络和安全可观测性平台。

Hubble能够利用Cilium提供的eBPF数据路径，获得对Kubernetes应用和服务网络流量的深度可见性。这些网络流量信息可以对接Hubble CLI、UI工具，可以通过交互式方式快速发现和诊断相关的网络问题与安全问题。除了自身的监控工具，Hubble还可以对接Prometheus、Grafana等主流的云原生监控体系，实现可扩展的监控策略。

2.5、安装

# 下载及解压
wget https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin# 安装
cilium install --kube-proxy-replacement=strict# 可视化组件
cilium hubble enable --ui# 查看状态
cilium status# 展示Service
cilium service list