云原生场景下的容器网络隔离技术

Posted 2023-03-30 每天一个秃顶小技巧

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生场景下的容器网络隔离技术相关的知识，希望对你有一定的参考价值。

云原生场景下的容器网络隔离技术

一、研究背景

随着云计算时代的到来，尤其是容器化技术的飞速发展，云原生作为云计算的未来阶段，其安全势必成为云安全的主要战场。从目前的云原生环境来看，云原生网络安全问题层出不穷，威胁程度逐渐上升，从业人员面临着严峻的挑战。

例如，此前Akamai公司进行了一项实验，将一个简单的Docker容器蜜罐用于攻击测试，结果显示该容器在24小时内被攻击者用于四起不同的犯罪活动，这些攻击的目的各不相同：一起攻击试图使用容器作为代理，以访问数据流或其他服务，另一起企图让目标感染僵尸网络，还有一起执行加密货币挖掘，最后一起是通过容器针对居家办公用户实施诈骗。

此外，2018年特斯拉AWS上部署的K8S Dashboard因为暴露在公网，没有做认证和授权控制，也没有对网络访问做控制，导致黑客直接从dashboard中获取S3凭证，从而获取遥测数据，恶意拉取POD，进行挖矿行为。

从上面案例我们可以看出，云原生安全不仅仅要应对传统安全问题，更面临着全新的挑战。在众多安全技术手段中，网络隔离技术作为最早、最基础、最为核心的安全技术手段之一，本文章也将重点围绕着网络隔离技术，以传统隔离与云原生隔离两个角度进行分析，着重对容器网络隔离技术做介绍。

二、传统的隔离技术–传统防火墙

随着云计算的普及，网络边界日渐模糊，这使得传统防火墙基于边界流量实现隔离显得有点格格不入，无法适配云原生场景下的隔离需求。

传统防火墙作为实现传统隔离的重要手段，在云原生场景下，主要面临着以下几个问题：

1. 容器 IP 的多变性，一旦容器ip地址改变，针对不变的ip地址为“锚点”实现的防火墙访问控制将无法生效;

2. 网络攻击隐蔽且多变，业务平台需更强的威胁识别和处置能力；

3. 云原生场景下，对灵活弹性扩展需求高，需要安全策略和能力快速匹配；

此外，在CNCF 发布的《云原生安全白皮书》也指出传统基于边界的安全防护机制，如防火墙等，在云原生的场景下很难面面俱到。所以，在云原生场景下，为了更好保护我们的业务容器安全，我们需要一些新的隔离技术去实现网络隔离。

三、云原生隔离技术–容器代理实现的隔离方法

3.1 基于k8s实现的容器隔离

关于云原生场景下的原生的网络隔离技术，其中Kubernetes提供了NetworkPolicy和istio中的AuthorizationPolicy ，两者都支持按Namespace级别的网络隔离，达到访问外部资源隔离的目的。其中NetworkPolicy还支持按pod级别去做网络访问控制，利用label指定namespaces或pod，底层通过iptables实现，是大家比较熟悉的pod访问控制实现技术，下面我们简单介绍一下NetworkPolicy的使用场景。

NetworkPolicy使用场景示例如下：

要求只容许指定pod访问服务：

其网络策略如下：

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:    //匹配的lable如下
      app: bookstore 
      role: api
  ingress:
  - from:
      - podSelector:
          matchLabels:      //指定可以容许访问的pod需要的lable
            app: bookstore

实现效果如下：

从上面示例可以看出，NetworkPolicy可以通过指定对应的labels实现对Namespace 和Pod 级别的网络隔离。对比于传统的单一外部防火墙，NetworkPolicy实现了在一个集群内的pod间网络隔离。也就是在某些需要的 Pod 之间架起防火墙，实现了细粒度的pod网络访问隔离策略。正是因为它的这些优点，目前市面上的容器安全产品的网络隔离有很多都有一些NetworkPolicy的影子。

但是如果要基于NetworkPolicy做一个安全产品的网络隔离技术时，NetworkPolicy还是存在着很多缺点，主要是以下几点：

性能差，无法满足大规模网络场景的隔离需求（目前各个cni在NetworkPolicy 的实现上，一般基于iptables的方式，假如流量或者需要管控的pod过多时，对集群性能影响较大，甚至可能导致 iptables不堪重负）；
适用性差，目前类似于Flannel 这种流行的cni插件，并没有实现对NetworkPolicy的支持。此外，对于非k8s的场景下，例如docker compose、docker Swarm、OpenShift等环境，NetworkPolicy并不能支持；
细粒度不够，目前NetworkPolicy只能实现对Namespace 和Pod 级别的网络隔离，对于docker直接起的业务容器，并不能够起到防护作用。此外，目前NetworkPolicy也只能做到四层网络的防护，并不能实现对第七层网络级别的防护；
易用性差，每次配置都需要创建对应的yaml、无法实现自动化部署，存在效率低的问题。此外，对于开发或者运维人员很难做到“一配即中”的效果，而规则错误很可能导致业务受影响，配置难度和试错成本极高；
灵活性差，云原生场景下，对灵活弹性扩展需求高，需要安全策略和能力快速匹配。

总的来说，NetworkPolicy在当前阶段，只适用于部分场景对小规模的pod进行网络隔离，不能作为一个成熟的网络隔离技术在安全产品中使用。

3.2 容器代理实现的隔离方法

由上可知，networkPolicy的实现方案存在着众多缺点，所以我们还是需要在云原生的场景下探索新的网络隔离方法，接下来我以容器代理的思路为大家介绍云原生场景下比较成熟的隔离方案。

在介绍容器代理的方式之前，先简单介绍容器之间的网络通信。首先无论pod还是docker之间的通信，它们都会在自己的网络命名空间下与节点上的网络命名空间建立veth对进行连接通信，这些虚拟接口可以分布在多个命名空间上。

下面以k8s的网络通信举例，在k8s中，将veth对一侧分配给 root network namespace也就是节点的网络命名空间，另一侧分配给 Pod 的网络命名空间。每个 veth 对就像一根网线，连接两侧并允许流量在它们之间流动，如下图：

基于上面的基础，我们可以在云集群中的每一个节点上部署一个代理容器，将被代理容器或者pod与宿主机通信的veth piar进行重组，通过代理容器的veth piar连接两侧，效果图如下：

通过上述代理容器的方式，我们可以对节点上面其他容器和pod进行流量控制。基于packet mmap对网络连接进行分析，实现对容器网络通信的网络访问控制，实现网络隔离的效果。

同时，它也解决了NetworkPolicy很多存在的缺点，具体为以下几点：

性能影响小，不需要添加多余的iptables规则，它可以通过TC或者XDP的方式对流量包进行转发，将性能影响降到最小；
适用性广，与网络插件解绑，同时支持docker compose、docker Swarm、OpenShift等环境；
细粒度更高，支持容器为最小控制单元；
灵活性高，满足云原生场景下灵活弹性扩展需求高的特点。

3.3 理想的容器网络隔离技术需要具备的特点 通过以上两种云原生网络隔离实现方式的分析，我们可以推断出一个理想的容器网络隔离技术需要满足以下特点：

性能影响，实现容器网络防护的同时，需要尽量不去影响集群性能和业务容器的正常运行；适用性，不应该局限于某一种场景，给用户带来迁移或者架构更新的成本；
细粒度，支持容器为新的最小控制单元。另外，目前主流的零信任产品网络防护只做到4层，理想的容器网络隔离技需要做到7层网络防护的效果；
安全策略能力，随着云原生可视化技术的成熟，是安全策略的实现基础，基于云原生场景下“东西向”和“南北向”流量的可视化，隔离技术需要实现策略的自动生成更新；
灵活性，针对云原生场景下灵活弹性扩展需求高的特点，隔离技术需要做到安全策略和能力快速匹配，实现快速部署以及弹性伸缩。

四、总结

本文从传统网络隔离与云原生网络隔离两个角度出发，分析了现有的网络隔离技术的特点，讨论了云原生场景下网络隔离技术需要满足的特点。

首先我们通过分析传统隔离得出，在面对复杂的云原生应用场景时，为了更好保护我们的业务容器安全，我们需要一些新的隔离技术去实现网络隔离。
然后，我们通过介绍目前云原生网络隔离的两种实现方案，得出一个理想的容器网络隔离技术需要满足哪些特点。
最后，希望通过本篇文章的分享，你能有所收获。

五、参考链接

1.https://ahmet.im/blog/kubernetes-network-policy/

2.https://kubernetes.io/docs/concepts/services-networking/network-policies/

3.https://www.51cto.com/article/715804.html 4.https://en.wikipedia.org/wiki/N

云原生容器场景下的内核安全

一、系统安全现状

首先我们来看一下系统安全，特别是系统安全的现状，这是Linux2008~2019年的内核代码的数量，然后到2019年已经超过2300万行，现在我们的最新统计数据是将近2800万行代码。

另一方面如果我们只看Linux内核，我们觉得它的代码量挺高的，但是我们如果把它放到整个安卓的生态里面来看，其实它只是在很小的一部分，在Linux内核之上，还有Hal hardware abstraction there这一层，上面还有Android的run time层，再往上面有安装的framework，还有applications。

二、攻防演化

代码量跟bug的数量或者说跟漏洞的数量它是成正比的，代码量越多，它的bug漏洞数目也会越大，所以这是Linux内核的一些现状。在最近一些年，它里面的bug数量每年都超过125，这都是Linux内核里边可以被利用的bug数量，代码量巨大就会导致新的漏洞，所以软件漏洞无法避免，这些软件漏洞往往会被攻击者利用，这就会产生新型的攻击。

另一方面，新型的攻击又催生了新型的防护，所以对操作系统内核的攻防是在不断的对抗中演化升级的，它的攻防不是静态的，不是一下子就能全部防住的，它是在不断对抗中演化升级，所以没有绝对安全的系统，也没有绝对强的攻击手段，他们都是相对在演化，所以我们有一张这样的图，如果来看我们攻防演化，我们按照这个手段对它进行分类的话，首先是代码注入攻击，然后防护代码注入攻击，研究人员提出了带数据不可执行，然后对进行防护。

攻击者发现他的攻击手段被防护了之后，进而提出了代码重用攻击，然后安全研究人员又提出了新型的防护，叫控制类完整性进行部分防护。在这之后攻击者又提出了数据攻击，而现在我们又提出了这个数据有完整性一些保护。

三、代码注入攻防

1、通过内核漏洞

篡改已有代码text section
注入新的代码
或者跳到用户代码，比如jump-to-user

2、系统控制能力大

可执行新代码
危害大

3、多见于早期Linux

比如Kernel Text RWX (Android 2013)

4、内核代码注入防护

保护已有代码W^X
硬件支持，杜绝注入
数据不可执行(2001 XN ARM; NX AMD)
特权不可执行(2011 SMEP Intel; PXN ARM)

5、通过内核页表来实现

在内核页表设置相应的保护位，实现保护
多数Android设备, 包含Google Pixel
防御性弱，内核页表被改掉即失效
对内核页表没有保护
攻击者可篡改页表，去掉保护
进而篡改代码

6、通过隔离环境保护内核页表

通过隔离环境，避免内核漏洞影响
实现了纵深防御defense-in-depth

四、内核代码重用攻击

无法注入新代码，重用已有代码，通过篡改控制流，拼接已有函数片段，实现攻击函数，也被称为控制流劫持攻击。

五、内核数据攻击

1、控制数据被保护后，攻击者提出非控制数据攻击

返回地址和函数指针以外的数据
Data-oriented programming
影响关键的安全特性
仅利用非控制数据攻击做到内核提权

2、非控制数据防护

非控制数据攻击的一个例子就是s一Linux绕过，在Linux内核的代码44.4版本里发现一个全局变量，如果是0，就会永远是真，所以就永远绕过，攻击者一般拿到这个之后，获得了内存的读写权限，首先把变量写成0，Linux的所有检查都会绕过，但是现在对于非控制数据还没有很好的有效防护，所以现在主流的操作系统也都没有部署对数据攻击的有效防护。

六、内核攻防演化

1、攻击演化

它的攻击复杂性在指数增进，同时它的隐蔽性也在增加，代码注入工具很容易被检测，因为它改了代码或者增加了代码，代码重用攻击只改了written Reiss的方向，所以它已经比较难检测，而数据攻击就更难检测，这么多数据，你根本不知道哪些被篡改。

虽然这个攻击的难度在增加，但对于我们比较有利的是它的控制能力却在减少，代码注入攻击能力最强，代码注入攻击可以拼接代码片段，也可以做到图例完整。

数据攻击就只能通过筛选数据，并且你的攻击范围只能是数据控制的一些代码，所以它的控制能力在减弱，但是它依然能够入侵操作系统内核，依然能够做到权限提升，所以数据攻击危害性还是很大。

2、防护演化

防护方面的演化，每一个攻击出来，首先都会提出一些防护的方案和解决思路，并且一般都是通过一些学术论文发表，大家提出的防护方案，后续这些学术的原型软件的方案通过沉淀，通过不断的优化，硬件厂商会把它做到硬件化，比如说后面会有一些AMD或者intel，会把它真正的实现到硬件里面来提供支持。

硬件首先能提高安全性，其次能减少性能开销，所以一般硬件被防护机制支持后，这种安全机制一般会大规模的商用，这就是防护的研发趋势，从软件到硬件，从学术界的原型到产业界的实用方案。

3、防护方案的滞后性

对于代码注入攻击，最早是在1988年出现的，到2001年才有硬件的防护方案，所以滞后13年，代码重用攻击滞后17年，而数据攻击到现在还没有很好的防护方案，所以它的滞后性肯定会更多。

4、最近几年的攻击方式总结

下面对攻击方法进行一个总结，这是最近几年的一些总结，蓝色的是代码重用攻击，红色的是数据攻击。这里面我们可以看到代码注入攻击已经很少了，一些比较有名的论文，都是基于代码重用攻击或者数据攻击的。

这里面每一个有图标的都是一个真实的攻击案例。

我们总结一下防御的方法，防御的方法就是内存的安全问题，主要可以归为两类，一个是越界的独，一个是越界的写。

越界的读，如果它读了不该读到的数据，就会造成一个Information。越界的写，如果他写代码的话，它就是代码输入攻击，如果他写控制数据，它就是代码重用攻击，也要控制这个攻击，如果他写非控制数据的话，叫面向数据，这是传统的系统内核攻防的演化，现在这个容器应用更加广泛了，容操系统在容器的场景下，面临一些特殊的安全挑战。

七、容器介绍

1、什么是容器

容器是操作系统级虚拟化，它是由同一个内核虚拟出来多个用户空间的实例，每个用户空间的实例，不需要维护单纯的内核，用户空间的实例，也叫容器实例，它不用单独维护内核，所以它效率高，启动快，并且配置比较灵活，会被广泛应用于代码。

2、操作系统级虚拟化

由同一内核虚拟出多个用户空间实例，无需维护单独内核

3、具有效率高、启动快、配置灵活等特点

3、由namespaces负责隔离

首先是提供了namespace，它负责隔离，namespace相当于镜像。如果我们说一种资源，它被namespace的，就说这个资源在容器看到的跟 Linux内核外边看到的是不一样的，相当于给容器一个单独的镜像，现在内核支持了8种namespace，这叫资源的限制，叫control group，它可以限制CPU，可以限制内存，可以限制一些设备资源，它可以限制你用了多少CPU，用了多少内存，对IO的访问速度是多少。