关于容器网络安全困境的路径探析

◆陈远峥 郭 岳

（中国移动通信集团浙江有限公司 浙江 310030）

1 K8S环境下的容器网络与安全

1.1 安全风险

关于容器和K8S的安全性与隔离的问题已经被暴露过很多的BUG和漏洞，并引发了广泛的讨论。从根本来说，Docker使用了cgroup来做了运行时隔离，从本质而言，每一个Docker Host的容器，都是一个操作系统（OS）下的不同环境，但是仍然共享内核，即使容器和K8S可以通过Namespace（命名空间）为安全边界来实现租户级别的隔离，但是还是无法解决安全隐患。

从整个社区来看，共用内核的容器在安全隔离上还是比较弱。虽然内核在不断地增强自身的安全特性，但由于内核自身代码极端复杂，漏洞层出不穷。比较典型的是容器挖矿程序，利用某一个服务漏洞入侵容器环境，占用CPU资源进行挖矿，并且在内网中迅速蔓延、渗透，侵占数据中心资源，造成业务停滞。曾被爆出在Docker Hub上有17个容器镜像带有挖矿后门，这些镜像一共被下载了500万次[1]，这个病毒在容器社区造成严重影响。

在企业内部来说，我们历经多年的微服务化改造，目前在运行的容器环境已经初具规模，容器数量多，并且和虚拟机相比，容器的物理整合比更高，在几百台服务器的集群上就运行了几万个容器。每个服务器原来就一个或几个地址对外服务，而运行容器环境时，每个服务器的容器对外访问的需求大大增多，这样一来整个集群所暴露的安全风险点，也同样放大了几十倍，安全运维难度也同比增大几十倍。

2 容器安全问题分析

通过几年下来的容器运维经验积累，在容器安全方面，我们遇到了几个较为棘手的难题：

2.1 如何进行容器的精确安全隔离

业务微服务化拆分后，内部的东西向的流量急剧放大，如何做好东西向的容器安全分级管控和安全隔离？

集群中有着来自不同业务域的容器应用，如果想管理不同业务域的容器间的流量，目前还只能够在硬件级进行隔离，这样所有的流量都不得不经过硬件交换设备，增加容器环境的网络复杂度，并且会形成“发夹效应”，从而降低了数据传输效率，增加了网络流量和硬件设备的传输压力。

如CNCF的K8S容器平台的安全最佳实践文档中[2]的第6条：创建和定义集群网络策略的要求；和第7条：运行集群范围的Pod安全策略。都是要求从容器级别实现隔离或者打通等安全管控。能够在不同业务的容器之间，按照既定规则-标签、地址、端口等限制，来实现网络分段，实现策略化的安全隔离。

大规模的复杂业务域的容器环境该如何实现细颗粒度的安全隔离？

2.2 如何实现容器的精细化流量控制

如前面所说，随着物理服务器的CPU和内存配置越来越高，一台物理服务器上运行的容器数量不断增多，而物理机的业务网卡总数量和吞吐量有限，如果其中一个或几个Pod占用服务器过高带宽，造成了网络带宽资源不平衡，从而造成同服务器上其他所有的容器的吞吐受限，响应时间变差。

针对业务激增或异常，如何将有效关键带宽资源预留和限制，如何针对容器设置网络的流量和带宽管理，一直没有良好精细化容器网络QoS的手段。

2.3 如何防止容器的IP地址假冒攻击

容器平台的容器数量越来越多，对外暴露的风险点也会成倍增加，一旦有一个容器被攻破，会尝试做修改IP、嗅探内部漏洞等动作，绕过简单的容器安全防护，对其他容器业务、甚至虚拟机、物理机进行内部探测和破坏。可见，当攻击行为成功绕过南北防火墙之后，对内部造成的破坏会是非常巨大且很危险。

不仅是攻破一个容器，前面描述的漏洞中还会可能通过攻破容器再获取整个主机的管理权限，在整个网络内部做更深度的攻击和破坏，如何能够避免此类攻击，一直是一个重要问题。

2.4 如何防止容器挖矿类型病毒

容器挖矿病毒的到处肆虐，利用多个软件不同版本的各种漏洞，渗透到内部环境，来注入挖矿木马，并且在内部网到处嗅探、传染，此前的解决方法往往是发生了一次后，升级解决某个软件版本的漏洞，删除被感染环境的木马程序，但是各个软件升级调整又有新的漏洞以及源源不断的新木马变种，层出不穷。希望能找到一种有效的方法来避免此类问题的发生。

3 开源容器网络组件的现状

在数据中心发展多年以来，现有网络环境有各种安全管理手段，但是容器作为一个新兴环境，是独立于其他资源池独立存在。容器池功能都还在小规模测试、试用阶段，对于容器资源池的安全，业内考虑不多，都以单独组网，做物理的南北向管理为主。

Docker容器默认可以配置基本的网络组件，但是还远远不够。CNCF（cloud native computing foundation）创建了一个统一的网络框架CNI（container network interface）来规范网络插件接口，让容器运行时与插件进行协作。目前流行的网络插件主要有：Flannel、Calico、Macvlan 和 NSX-T。

K8S的网络功能：

K8S自身设立了租户-Namespace来进行资源分配和管理，但是每个租户内地址是杂乱无章的，并且租户之间网络完全互通。各个节点Node内所有pod的南北向流量都需要NAT成节点地址，无法基于租户运维和进行安全策略控制

Flannel开源网络优缺点：

优点：Flannel采用etcd实现Ip地址的统一管理，避免集群Scale out导致的Ip地址冲突等问题，并且节点node之间配置overlay网络，集群的Scale out无须配置外部物理网络。

缺点：

（1）在Flannel的网络中租户NameSpace和网络之间无对应关系；

（2）缺乏基于容器颗粒度的安全管控；

（3）不支持Network policy；

（4）南北向流量需要基于节点node做nat；

（5）缺乏路径跟踪、QOS、SPAN/netflow、可视化等端到端运维能力；

（6）更为重要的是基于iptable的东西向负载均衡，性能无法满足生产业务的需求；

（7）南北向负载均衡需要借助其他第三方开源软件；

（8）开源网络的可靠性和服务支持严重不足。

Calico开源网络优缺点：

优点：基于Calico的容器网络配置简单，通过 BGP主机路由实现Pod的网络连接支持跨节点的路由模式，支持Network Policy。

缺点：相较企业级容器网络其不足非常明显。

（1）NameSpace和网络之间无对应关系，无法基于租户进行逻辑网络的定义和边界映射；

（2）南北向缺省情况下需要基于节点node做NAT；

（3）Network配置运维功能不足；

（4）缺乏全面的容器颗粒度的安全管控；

（5）缺乏端到端运维：路径跟踪、QOS、SPAN/netflow、可视化等；

（6）更为重要的是基于iptable的东西向负载均衡，性能无法满足生产业务的需求；

（7）南北向负载均衡需要借助其他第三方开源软件；

（8）开源网络的可靠性和服务支持严重不足。

Macvlan开源网络优缺点：

优点：基于Macvlan的容器网络配置简单，通过子接口实现Pod的网络连接支持跨节点的路由模式，无须每个节点配置NAT。

缺点：

（1）节点扩展时，外部物理网络手动修改路由；

（2）没有统一IP地址管理，节点的扩展很容易造成Ip地址的冲突；

（3）NameSpace和网络之间无对应关系，无法基于租户进行逻辑网络的定义和边界映射；

（4）缺乏基于容器颗粒度的安全管控；

（5）缺乏端到端运维：路径跟踪、QOS、SPAN/netflow、可视化等；

（6）基于iptable的东西向负载均衡无法生产业务的需求；

（7）南北向负载均衡需要借助其他第三方开源软件；

（8）开源网络的可靠性和服务支持严重不足。

Flannel、Calico、Macvlan都能够提供基本的容器网络连接，但是普遍问题是东西向的Iptable的低下的效率和性能，对于生产环境是一大瓶颈；缺乏南北向负载均衡，缺乏全面安全管控，缺乏可视化运维工具和可靠的支持。这几个开源组件目前都无法解决当前已经遇到的容器网络安全问题。

NSX-T作为商业数据中心网络和安全组件，经过多轮测试和使用，我们发现，NSX-T可以针对每个Namespace分配一个交换机环境，分配内网or外网地址段，来实现业务容器的微分段，根据业务的属性定义标签，通过安全五元组来实现访问与控制策略，并且将容器直接互相访问的端到端可视化，迅速定位网络访问的故障和问题，实现快速排障。

4 解决方法

容器网络一直是K8S中的弱项，虽然有多种开源的容器网络工具，但是功能全、安全可靠、方便运维的网络工具一直比较缺乏。经过一系列的对比和功能调试，我们选用了NSX-T软件定义网络软件，目前是K8S容器平台的非常强大的组件，除了很好的支持容器网络，还能打通VM、裸机、KVM等多资源池的网络环境。接下来详细介绍下，NSX-T如何解决上面提出的两个容器网络难题。

4.1 容器的安全隔离

首先，NSX-T和K8S的API server深度集成，在通过kubectl命令创建Namespace时，NSX-T会自动分配独立的路由器、地址段，如下图1所示。这样基于容器应用安全的要求，可以基于单个Pod或一组Pod进行网络的微分段。

图1 容器分段1

然后是控制业务网络的路由策略，将来自不同业务的容器，如CRM和BOSS应用，按照标签对应用分类标记，或Network Policy（k8s 1.7发布功能），如图2、图3来为容器细致分段。

图2 容器细致分段2

图3 容器细致分段3

最后，通过定制安全规则，指定源、目的、服务类别、动作、实施范围的五元组，来实现网络的精细流向限制、端口限制等高级策略和精细化管理，访问规则既可以提前预定，也可以用命令实时创建，如图4。流量管理在物理机的网卡层即可实现控制，既可以减少需要屏蔽的流量对于网络的影响，又能增加数据传输与交换的效率，减少‘发夹效应’。这样在k8s管理的容器集群内部就能实现流量安全管控与隔离。并且，NSX-T还能够建立跨容器、虚拟机、KVM、裸机等不同状态的应用使用统一的安全策略的集中管控，这个在后续文章中详细探讨。

4.2 容器的精细化流量控制

NSX-T可以根据业务需要基于每个pod的端口进行入向或出向端口的流量限速，以保证不同应用访问的服务质量，同时也可以对每个POD端口的广播流量进行入口限速，如图5、图6。另外也可以根据需要对每个POD端口进行DSCP或CoS值的设定。这样针对突发业务激增或异常，可以有效管理带宽资源预留和限制。

4.3 防止容器的IP地址假冒攻击

网络的攻击常会从安全重视程度不高的边缘、非核心业务入手，容器一旦被攻破，攻击会尝试各种办法来突破防御。对于尝试更改IP地址的攻击行为，NSX-T使用Spoofguard功能，维护容器名称和 IP地址的引用表来防止 IP欺骗，如图7。在容器的初始启动过程中，用检索到的信息填充它与每个容器的IP地址，可阻止未知的虚拟机发送或接受流量，大大提高了容器网络的整体安全性。

图4 安全规则

图5 应用场景

图6 测试结果

4.4 容器挖矿病毒处理

容器挖矿病毒，例如minerd挖矿程序。利用Jenkins、Redis等中间件的漏洞发起攻击，获得root权限，植入挖矿木马，消耗CPU、GPU资源来进行挖矿，并且利用masscan端口扫描特定端口如TCP 2375和2376，来获取可以通讯的服务器进行传染。了解了基本原理可以进行一步步的容器环境安全加固：

（1）在整个容器集群，屏蔽常见的挖矿网站的服务器地址列表；

（2）限定可以连接如Redis服务器的IP范围，只有特定的地址可以访问，减少对外暴露，并修改redis的默认端口6379；

（3）容器集群封堵高风险端口，如TCP 2375和2376等；

（4）严格限定同业务域以及不同业务域的容器之间的访问规则，如限制访问来源为特定的IP地址加上特定端口。

图7 防止容器的IP地址假冒攻击

总的来说如果容器被攻击，流量已经被NSX-T的安全隔离的微分段策略进行了访问限制、端口限制等严格管理；如果尝试手工修改地址来尝试在内部进行扫描和攻击，由于容器地址假冒被策略禁止，可以解决这个隐患；如果宿主机权限因为异常被用户获取，并更新了主机信息，假冒一个新的主机来尝试内部攻击，NSX-T也能很好解决，因为主机的流量都是通过NSX-T的overlay来管理，新的主机网络无法在NSX-T环境中合法注册，因而无法获得在业务网络中运行的权限。

5 结论

针对容器网络的安全问题，结合了商业化的容器网络组件NSX-T，解决了前期困扰许久的容器网络安全隐患，实现了容器环境微分段管理，精细化控制管理容器环境内部东西向流量，加强了容器网络安全边界，有效预防了容器被攻击，控制了容器被攻破后的影响访问，在当前数据中心中建立了一个安全可靠的容器环境。