首页 > 代码库 > Cloud Foundry warden container 安全性探讨

Cloud Foundry warden container 安全性探讨

本文将从Cloud Foundrywarden container的几个方面探讨warden container的安全性。

 

1. warden container互访


1.1.  互访原理

Cloud Foundry内部,用户应用的运行环境通过warden container来进行隔离。

其中,网络方面,container之间的互访如下图:



假设container1主动访问container3

1.  container1从自身的虚拟网卡virtual eth0_0发起请求,由于自身内核路由表中的指向,请求发至virtual eth0_1(以下简称为网关);

2.  virtual eth0_1接受到请求,讲请求转发至host主机的物理网卡eth0

3.  host物理网卡eth0接收到请求,从而交给内核网络栈处理;

4.  请求在内核网络栈中的处理流程中,首先进行源地址转换(SNAT),使用host主机的eth0ip地址替换请求数据包的源ip地址,即讲10.254.0.2替换为10.10.18.83,随后在进行route路由转发;

5.  经过SNAT转换之后,请求发往内核路由部分,根据路由表中规则,请求将会转发至virtual eth2_1网关;

6.  请求回到host宿主机,开始发往virtual eth2_1网关;

7.  Virtual eth2_1网关接收到请求,根据规则转发至container3的虚拟网卡virtual eth2_0

 

       总体而言,所有从container内部发起的请求,只要经过host宿主机,在其内核网络栈中均会进行SNAT,随后进行route路由处理。这样的话,container之间的互访也就有了可能性。

 

1.2.  潜在安全问题

       Cloud Foundry是个多租户的PaaS云平台,不同租户的应用极有可能被部署在同一个DEA上的不同container内部。以上的分析表明,同个DEA上的不同container完全有可能进行互访,因此假设租户A的应用在containerA中,通过某些途径(如ip猜测,端口轮询等方式),可以获取到租户B的应用在containerB中监听的端口,那么租户A具备了攻击租户B应用的条件,从而存在安全隐患。

 

1.3.  解决方案设计

 

方案一:

        假设设计的目标是让所有的container之间都不具备互访的能力,则配置host宿主机的网络内核栈规则是一个可行的方案。

        1.1中的分析中可以得出结论,关于container发起的请求,在到达其他container之前都会经过host宿主机的eth0物理网卡。其中,在host宿主机内核网络栈中,进行规则处理,最后进行转发。

        container中发起的请求,会经过host宿主机的eth0物理网卡,因此可以在eth0将请求交给内核网络栈后,内核网络栈可以在进行SNAT处理之前先校验数据报的源ip地址以及目的ip地址。若源ip地址和目的ip地址均为DEA内部containerip地址,则将数据报直接丢弃。

 

       方案一中的设计,虽然可以满足container之间不能互访的要求,但是配置所有container之间不能互访的做法显得灵活性不足。

        假设租户A有多个应用分别运行在同一个DEA上的不同container内部,该场景使用方案一的话,租户A自己的应用也将不能互访,这大大降低了租户对运行环境要求的灵活性,也削弱了租户A应用的功能。


以下介绍方案二的设计。

 

方案二:

       引入应用安全组的概念,允许用户配置container的外出防火墙规则,主要为用户提供创建和隔离应用组的安全网络zone的概念。

       应用安全组的实现,使得租户A的应用container与其他租户的应用container保持网络不能互访,而对于同一个租户自己的多个应用,租户有权限根据需求进行配置,使得有需要的container之间可以进行互访,而没有需要的container之间不能互访。



2. ContainerCloud Foundry组件级别的互访

       目前Cloud FoundryDEA上运行的container可以访问任何Cloud Foundry的组件,相反Cloud Foundry任何组件都可以访问container,这显然是不利于整个平台的安全防护的。



2.1.  互访原理 

2.1.1. Container访问Cloud Foundry组件

        假设container发起请求,连接Cloud FoundryDEA外的其他组件,则该请求会在进行SNAT处理之后,有eth0进行转发,只要host宿主机与其他组件的机器保持网络畅通,则container完全可以与Cloud Foundry的其他组件进行通信。其中,container默认合法的访问组件只有gorouter以及service组件,若完成应用间通信的话,container与其他DEA之间的通信也将被认为合法,而和其他组件的通信均可以认为是非法的,具体流程图如下:


 

2.1.2. Cloud Foundry组件访问container

        该部分内容与2.1.1中大致相同。由于外界访问container的请求都会被做DNAT处理,因此所有能够访问container所在宿主机的Cloud Foundry组件都可以访问host主机,则均可以访问container。目前允许访问DEA内部containerCloud Foundry内部组件,只有gorouterservice,以及其他DEA(假设允许应用之间允许互相通信),而Cloud Foundry其他的组件访问container均被认为是非法的。

 

2.2. 潜在安全问题

2.2.1. Container非法访问Cloud Foundry组件的安全

       Cloud Foundry托管用户应用的运行,假设用户上传恶意应用,而恶意应用与Cloud Foundry其他的组件可以保持网络的畅通,则恶意应用完全有可能具有能力对Cloud Foundry的其他组件进行攻击,从而影响到整个平台的安全性。

 

2.2.2. Cloud Foundry组件非法访问container的安全

        原则上,由于Cloud Foundry组件是平台级别的,对container的访问理论上不会造成很大的影响。然而当Cloud Foundry平台级别的组件受到恶意攻击并被攻破,而DEAcontainer没有受到攻击的时候,假设Cloud Foundry组件还可以访问container,则恶意攻击还将蔓延至用户部署的应用上,而限制Cloud Foundry组件非法访问container的策略,可以在Cloud Foundry平台被攻击的情况下,大大提高用户应用的安全性。

 

2.3. 解决方案设计

        对于Cloud Foundrycontainer内部访问Cloud Foundry其他组件的情况,可以配置DEA所在的host宿主机防火墙规则来实现。

        container内部的请求发送至host宿主机的物理网卡eth0,在做SNAT地址转换之前,由宿主机内核网络栈对请求进行处理,如果目的ip地址不是gorouterservice或者dea的话,该数据报将会被丢弃。

        为实现以上的策略,DEA在启动之前需要获知所有Cloud Foundry内部组件的角色与IP地址映射关系,从而通过这些映射关系配置防火墙策略。


3. ContainerService组件的互访


3.1.  互访原理

       Cloud FoundryService的存在大大完善了应用的功能性。然而,目前Cloud Foundry内部的应用对于Service的访问,只需应用持有数个元素,即可以访问service instance,这些元素主要有5个,即service instanceipportusernamepasswordinstance name

        关于service instance访问请求的流程,与container访问Cloud Foundry其他组件的原理一致,如下图:


 

3.2.   潜在安全问题

        假设一个租户的应用非法持有了某service intance的这5个元素,那么此应用将会完全有能力访问该service instance。原先的Cloud Foundry对于这种情况,没有合适的应对措施,也就相当于默认service instance的这种安全隐患。

        以上的叙述可见,关于container访问service的安全隐患,主要体现在防范的局限性方面。因为所有的安全策略制定都依赖于service instancecredentials信息,也就是5元素上。在目前工业界中,依靠这部分的安全保护,已经显得不足。而且Cloud Foundry是一个面向多租户的PaaS,数据的安全性格外敏感,必须从多个维度来保护用户数据的安全性。

 

3.3.   解决方案设计

 

方案一:

       通过配置container所在的host宿主机防火墙规则,来实现合法应用对service instance的合法访问,并且阻止非法应用对service instance的非法访问。

具体实现如下:

1.   在应用和service instance绑定完毕之后,DEA会将service instancecredentials信息当作参数放入应用启动请求中;

Hongliang  Sun2.  DEA可以在启动应用之前,先提取containerip地址,以及service instanceip地址信息,从而在host宿主机上配置防火墙策略,实现,containerservice instance的合法访问,而没有绑定过service instancecontainer则在非法持有正确的credentials之后,也无法访问service instance

3.   当停止应用的时候,DEA首先解析containerip地址以及service instance的信息,随后删除防火墙记录。

 

方案二:

       通过配置service instance所在的Service Server所在节点,来实现合法应用对service instance的访问,并且阻止非法应用对service instance的非法访问。

具体实现如下:

1.   在应用和service instance进行绑定的时候,由Cloud Controller告知service server所在节点,绑定service instance的应用所属的IP:PORT映射对;

2.   Service Server所在节点,接收到Cloud Controller发送来的请求后,制定自身的防火墙策略,从而保证只允许绑定service instance的应用所对应的IP:PORT映射对才能访问该节点。

3.   当应用停止的时候,Cloud Controller发送请求给Service Server所在节点,由Service Server所在节点删除防火墙记录。 


        以上便是对Cloud Foundry中warden container的部分安全性探讨。

        未完待续。



转载请注明出处。

这篇文档更多出于我本人的理解,肯定在一些地方存在不足和错误。希望本文能够对接触Cloud Foundry v2中warden模块安全问题的人有些帮助,如果你对这方面感兴趣,并有更好的想法和建议,也请联系我。

我的邮箱:shlallen@zju.edu.cn
新浪微博:@莲子弗如清