Cloud Foundry warden container 安全性探讨

本文将从Cloud Foundry中warden 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主机的eth0的ip地址替换请求数据包的源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推測。port轮询等方式），能够获取到租户B的应用在containerB中监听的port，那么租户A具备了攻击租户B应用的条件，从而存在安全隐患。

1.3.  解决方式设计

方案一：

如果设计的目标是让全部的container之间都不具备互訪的能力。则配置host宿主机的网络内核栈规则是一个可行的方案。

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

从container中发起的请求。会经过host宿主机的eth0物理网卡，因此能够在eth0将请求交给内核网络栈后，内核网络栈能够在进行SNAT处理之前先校验数据报的源ip地址以及目的ip地址。

若源ip地址和目的ip地址均为DEA内部container的ip地址，则将数据报直接丢弃。

方案一中的设计，尽管能够满足container之间不能互訪的要求，可是配置全部container之间不能互訪的做法显得灵活性不足。

如果租户A有多个应用分别执行在同一个DEA上的不同container内部，该场景使用方案一的话。租户A自己的应用也将不能互訪。这大大减少了租户对执行环境要求的灵活性，也削弱了租户A应用的功能。

下面介绍方案二的设计。

方案二：

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

应用安全组的实现，使得租户A的应用container与其它租户的应用container保持网络不能互訪。而对于同一个租户自己的多个应用，租户有权限依据需求进行配置。使得有须要的container之间能够进行互訪，而没有须要的container之间不能互訪。

2.
Container与Cloud Foundry组件级别的互訪

眼下Cloud Foundry中DEA上执行的container能够訪问不论什么Cloud
Foundry的组件。相反Cloud Foundry不论什么组件都能够訪问container，这显然是不利于整个平台的安全防护的。

2.1.  互訪原理

2.1.1.
Container訪问Cloud Foundry组件

如果container发起请求，连接Cloud Foundry除DEA外的其它组件，则该请求会在进行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内部container的Cloud
Foundry内部组件，仅仅有gorouter。service，以及其它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平台级别的组件受到恶意攻击并被攻破，而DEA的container没有受到攻击的时候。如果Cloud
Foundry组件还能够訪问container。则恶意攻击还将蔓延至用户部署的应用上。而限制Cloud Foundry组件非法訪问container的策略，能够在Cloud Foundry平台被攻击的情况下，大大提高用户应用的安全性。

2.3. 解决方式设计

对于Cloud Foundry内container内部訪问Cloud Foundry其它组件的情况。能够配置DEA所在的host宿主机防火墙规则来实现。

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

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

3.
Container与Service组件的互訪

3.1.  互訪原理

Cloud Foundry中Service的存在大大完好了应用的功能性。然而。眼下Cloud Foundry内部的应用对于Service的訪问，仅仅需应用持有数个元素，即能够訪问service
instance。这些元素主要有5个，即service instance的ip、port、username、password和instance
name。

关于service instance訪问请求的流程，与container訪问Cloud Foundry其它组件的原理一致，例如以下图：

3.2.   潜在安全问题

如果一个租户的应用非法持有了某service intance的这5个元素，那么此应用将会全然有能力訪问该service instance。

原先的Cloud
Foundry对于这样的情况，没有合适的应对措施，也就相当于默认service instance的这样的安全隐患。

以上的叙述可见，关于container訪问service的安全隐患，主要体如今防范的局限性方面。由于全部的安全策略制定都依赖于service
instance的credentials信息。也就是5元素上。在眼下工业界中，依靠这部分的安全保护。已经显得不足。并且Cloud Foundry是一个面向多租户的PaaS，数据的安全性格外敏感，必须从多个维度来保护用户数据的安全性。

3.3.   解决方式设计

方案一：

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

详细实现例如以下：

1.  
在应用和service instance绑定完成之后，DEA会将service instance的credentials信息当作參数放入应用启动请求中；

2.  DEA能够在启动应用之前，先提取container的ip地址，以及service
instance的ip地址信息，从而在host宿主机上配置防火墙策略，实现，container对service instance的合法訪问，而没有绑定过service
instance的container则在非法持有正确的credentials之后。也无法訪问service instance。

3.  
当停止应用的时候，DEA首先解析container的ip地址以及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的部分安全性探讨。

未完待续。

关于作者：

孙宏亮，DAOCLOUD软件project师。两年来在云计算方面主要研究PaaS领域的相关知识与技术。

坚信轻量级虚拟化容器的技术，会给PaaS领域带来深度影响，甚至决定未来PaaS技术的走向。

转载请注明出处。

本文很多其它出于我本人的理解，肯定在一些地方存在不足和错误。希望本文可以对接触warden安全性的人有些帮助。假设你对这方面感兴趣，并有更好的想法和建议。也请联系我。

我的邮箱：allen.sun@daocloud.io

新浪微博：@莲子弗如清