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

研究背景

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

例如，此前 Akamai 公司进行了一项实验，将一个简单的Docker 容器蜜罐用于攻击测试，结果显示该容器在 24 小时内被攻击者用于四起不同的犯罪活动，这些攻击的目的各不相同：一起攻击试图使用容器作为代理，以访问数据流或其他服务；另一起企图让目标感染僵尸网络；还有一起执行加密货币挖掘；最后一起是通过容器针对居家办公用户实施诈骗。此外，2018 年特斯拉 AWS 上部署的 K8S Dashboard 因为暴露在公网，没有做认证和授权控制，也没有对网络访问做控制，导致黑客直接从 dashboard 中获取 S3 凭证，从而获取遥测数据，恶意拉取 POD，进行挖矿行为。

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

传统的隔离技术--传统防火墙

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

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

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

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

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

所以，在云原生场景下，为了更好保护我们的业务容器安全，我们需要一些新的隔离技术去实现网络隔离。

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

基于 k8s 实现的容器隔离

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

NetworkPolicy 使用场景示例如下：

要求只容许指定 pod 访问服务，其网络策略如下：

kind: NetworkPolicyapiVersion: networking.k8s.io/v1metadata:name: api-allowspec:podSelector:matchLabels: //匹配的lable如下app: bookstorerole: apiingress:- from:- podSelector:matchLabels: //指定可以容许访问的pod需要的lableapp: bookstore

实现效果如下：

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

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

1. 性能差，无法满足大规模网络场景的隔离需求（目前各个 cni 在 NetworkPolicy 的实现上，一般基于 iptables 的方式，假如流量或者需要管控的 pod 过多时，对集群性能影响较大，甚至可能导致 iptables 不堪重负）；

2. 适用性差，目前类似于 Flannel 这种流行的 cni 插件，并没有实现对NetworkPolicy的支持。此外，对于非k8s的场景下，例如docker compose、docker Swarm、OpenShift等环境，NetworkPolicy并不能支持；

3. 细粒度不够，目前 NetworkPolicy 只能实现对Namespace 和 Pod 级别的网络隔离，对于 docker 直接起的业务容器，并不能够起到防护作用。此外，目前NetworkPolicy 也只能做到四层网络的防护，并不能实现对第七层网络级别的防护；

4. 易用性差，每次配置都需要创建对应的 yaml、无法实现自动化部署，存在效率低的问题。此外，对于开发或者运维人员很难做到“一配即中”的效果，而规则错误很可能导致业务受影响，配置难度和试错成本极高；

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

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

容器代理实现的隔离方法

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

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

下面以 k8s 的网络通信举例，在 k8s 中，将 veth 对一侧分配给 root network namespace 也就是节点的网络命名空间，另一侧分配给 pod 的网络命名空间。每个 veth 对就像一根网线控制着两侧流量在它们之间流动，以此为基础实现 pod 的网络通信。类似于下图：

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

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

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

1. 性能影响小，不需要添加多余的 iptables 规则，它可以通过 TC 或者 XDP 的方式对流量包进行转发，将性能影响降到最小；

2. 适用性广，与网络插件解绑，同时支持 docker compose、docker Swarm、OpenShift 等环境；

3. 细粒度更高，支持容器为最小控制单元；

4. 灵活性高，满足云原生场景下灵活弹性扩展需求高的特点。

理想的容器网络隔离技术需要具备的特点

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

1. 性能影响，实现容器网络防护的同时，需要尽量不去影响集群性能和业务容器的正常运行；

2. 适用性，不应该局限于某一种场景，给用户带来迁移或者架构更新的成本；

3. 细粒度，支持容器为新的最小控制单元。另外，目前主流的零信任产品网络防护只做到 4 层，理想的容器网络隔离技术需要做到 7 层网络防护的效果；

4. 安全策略能力，随着云原生可视化技术的成熟，是安全策略的实现基础，基于云原生场景下“东西向”和“南北向”流量的可视化，隔离技术需要实现策略的自动生成更新；

5. 灵活性，针对云原生场景下灵活弹性扩展需求高的特点，隔离技术需要做到安全策略和能力快速匹配，实现快速部署以及弹性伸缩。

总结

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

首先，我们通过分析传统防火墙得出，在面对复杂的云原生应用场景时，为了更好保护我们的业务容器安全，我们需要一些新的隔离技术去实现网络隔离。

然后，我们通过介绍目前云原生网络隔离的两种实现方案，得出一个理想的容器网络隔离技术需要满足哪些特点。

最后，希望通过本篇文章的分享，你能有所收获。深信服千里目安全技术中心创新研究院云安全研究团队也将对此持续探索研究。

参考链接

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/Netfilter

声明：本文来自深信服千里目安全技术中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。