酷应用

【容器安全技术报告】容器网络访问控制机制分析

百家作者：绿盟科技 2018-12-20 09:32:58

一

引言

随着容器技术成熟和敏捷开发的推广，微服务技术在业界越来越得到普遍的应用，但业务微服务化后又引入了一些新的安全挑战，特别是在访问控制层面。例如：

(1) 容器部署可以根据需求动态扩展，但也导致容器IP和端口频繁变换，所以基于静态的IP和端口的防护规则会失效；

(2) 东西流量剧增，约为南北流量的20多倍，要防护来自大量虚拟网络的东西向流量就需要设置大量防火墙规则，规则匹配导致的计算和时间开销将会成为一大问题；

(3) 微服务环境下的访问控制需发生在每一工作负载（workload）内，即提供端点（endpoint）到端点（endpoint）的访问控制，广泛部署的访问控制点应足够轻量，否则单点所增成本将迭代地引起总体成本的剧增。

那么面对上述三种挑战，容器环境中的访问控制机制应该作何改变呢？

二

容器环境下的防火墙

防火墙是实现访问控制不可或缺的手段，它与网络环境是息息相关的，网络环境的变化会对其提出一些新的要求。

在传统环境中：

1. 网络是相对静态的，大多网络防护规则都是基于静态的IP地址和端口的；

2. 内部是默认可信的，网络边界较清晰，访问控制机制部署在网络边界处；

3. 大部分的网络流量会经过网关

在容器环境中：

1. 容器的新增和消亡总在发生，IP分配变换频繁；

2. 多应用混合部署，边界不清晰。内部通信关系极其复杂，无法预先设置安全防护策略；

3. 容器间流量可见性差，为了检测和防护看不见的流量，我们想到了引流，但大范围引流很容易制造出新的瓶颈点，这在东西流量剧增的微服务环境下也不太现实，但不管如何变化，通过防火墙实现网络访问控制的功能没有变化，只是对防火墙的实现方式提出了新的挑战。

容器环境中网络防护如下图所示：

常见的防火墙形态主要包括：

1) L3/L4层包过滤技术：传统环境下网络拓扑相对稳定，包过滤规则也相对固定，而容器环境下网络漂移随时都在发生，包过滤规则需要根据网络变化随时调整包过滤规则。在Kubernetes环境下我们可以借助于NetworkPolicy或者一些其它的工具来动态更新规则，因为NetworkPolicy是基于Pod的，在容器部署发生变化时也可以进行动态保护。

2) 应用防火墙：容器环境下的应用防火墙通常需要与容器运行时或者容器编排工具集成，借助于DPI（深度包检测）技术来保护容器间的通信，同时借助于行为学习自动创建防护策略来保护容器环境。通过识别流量的应用信息，可实现面向业务的动态微分段，成为了保护东西向流量场景中容器应用免受恶意攻击第一道防线。

3) Web应用防火墙：运行Web应用程序、面向互联网的容器可以通过检测常见攻击的方法进行保护，这符合传统的Web应用程序防火墙功能。但是，要知道这仅限于常见的外部攻击，对于容器之间的访问防护还需分析它们之间的通信协议。

总之，传统的防火墙已不能满足容器环境下的访问控制，要达到更细粒度的访问控制，须采用可以动态感知资产、资产的属性和连接点等信息变化的新型防火墙，才可以有效防止源于内部应用程序级别的攻击。

三

容器环境下的访问控制机制

访问控制和网络隔离做为计算机网络的两大防护手段，由于篇幅原因，在此我们只谈访问控制，以Kubernetes为例来说明。

默认情况下，Kubernetes中的Pods不严格限制任何输入流，也不设置防火墙规则来限制Pod间的通信。当Kubernetes被用作多租户平台或共享PaaS时，对工作负载进行适当的访问限制就显得非常必要。Kubernetes在这方面也做出了努力，NetworkPolicy是Kubernetes社区提出的网络访问控制的官方解决方案。下面的访问控制也是基于NetworkPolicy展开的。

NetworkPolicy提供了基于策略的网络控制，用于隔离应用并减少攻击面。它使用标签选择器模拟传统的分段网络，并通过策略控制它们之间的流量以及来自外部的流量，其主要作用于网络层和传输层。

Kubernetes NetworkPolicy特点：

1.网络策略是针对于pod的，适用于一个pod或一组pod。如果一个指定的网络策略应用于一个pod，那么对pod的流量是由网络策略的规则决定的。
2.如果一个pod没有应用任何NetworkPolicy，那么该pod将接受来自所有来源的流量。
3.网络策略可以在入口、出口或两个方向为pod定义流量规则。默认情况下，如果没有显式指定任何方向，则对入口方向应用网络策略。
4.将网络策略应用到pod时，策略必须有明确的规则来指定入口和出口方向允许流量的白名单。所有不符合白名单规则的流量将被拒绝。
5.多个网络策略可以被运用到任何pod上。匹配到任何一条网络策略的流量都是被允许的。
6.网络策略作用于连接而不是单个数据包。例如，如果配置策略允许从pod A到pod B的流量，那么也允许从pod B到pod A连接的返回包，即使有策略不允许pod B发起到pod A的连接。

在Kubernetes中一切对象皆资源，定义NetworkPolicy资源的yaml文件中的spec字段数据结构展开图如下所示：

由上图可知NetworkPolicy通过podSelector、namespaceSelector来筛选pod，还有就是通过IPBlock，它的访问控制粒度是pod或者CIDR级别的，通过Ingress和Egress分别定义进出pod的流量。要知道的是NetworkPolicy只制定了策略，并没有对策略进行实现，策略的实现还要依赖于网络插件驱动，即需要各网络插件自己实现NPC（network policy controller）。有关如何编写NetworkPolicy的yaml文件可以参考官方文档，在这里不详细叙述。

此外，不同的插件对于NetworkPolicy的实现程度也不一致。