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

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

一、研究背景

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

例如，此前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