本文将从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
新浪微博:@莲子弗如清

Cloud Foundry warden container 安全性探讨的更多相关文章

  1. Cloud Foundry中warden的网络设计实现——iptable规则配置

    在Cloud Foundry v2版本号中,该平台使用warden技术来实现用户应用实例执行的资源控制与隔离. 简要的介绍下warden,就是dea_ng假设须要执行用户应用实例(本文暂不考虑ward ...

  2. Cloud Foundry中DEA与warden通信完毕应用port监听

    在Cloud Foundry v2版本号中,DEA为一个用户应用执行的控制模块,而应用的真正执行都是依附于warden. 更详细的来说,是DEA接收到Cloud Controller的请求:DEA发送 ...

  3. Cloud Foundry中DEA启动应用实例时环境变量的使用

    在Cloud Foundry v2中,当应用用户须要启动应用的实例时.用户通过cf CLI向cloud controller发送请求,而cloud controller通过NATS向DEA转发启动请求 ...

  4. Cloud Foundry技术全貌及核心组件分析

    原文链接:http://www.programmer.com.cn/14472/ 历经一年多的发展,Cloud Foundry的架构设计和实现有了众多改进和优化.为了便于大家了解和深入研究首个开源Pa ...

  5. 使用 Azure CLI 在 Azure China Cloud 云平台上手动部署一套 Cloud Foundry

    这篇文章将介绍如何使用 Azure CLI 在 Azure China Cloud 云平台上手动部署一套 Cloud Foundry.本文的目的在于: 了解作为 PaaS 的 Cloud Foundr ...

  6. Cloud Foundry和微服务Meetup重磅来袭

    CF 同学们: Cloud Foundry 2016 上海 Meetup 将在10月22日在上海港汇广场进行! 想要参会的小伙伴,请直戳  ~ 在过去的一年,CF 的技术有很多进展,微服务也是2016 ...

  7. Pivotal Cloud Foundry学习笔记(1)

    PCF是一个PAAS平台 注册PCF账号 https://account.run.pivotal.io/sign-up 安装cf CLI 访问 https://console.run.pivotal. ...

  8. Cloud Foundry v2 部署及入门运维

    之前写过一个Guide for Cloud Foundry New Teamer.不过似乎已经有些过时,那会实验室主要是针对的CF v1进行的研究,现在已经全面进入V2时代了.所以更新一下关于Clou ...

  9. Deploying Cloud Foundry on OpenStack Juno and XenServer (Part II)

    link http://rabbitstack.github.io/deploying-cloud-foundry-on-openstack-juno-and-xenserver-part-ii/ L ...

随机推荐

  1. spring mvc 的基本注解

    刚开始学习spring mvc 有很多东西不是很了解 spring mvc 四个基本注解 annotation(控制层,业务层,持久层) -- @Component.@Repository   @Se ...

  2. Ubuntu 14.04 上使用 Nginx 部署 Laravel

    本教程将会涉及以下工具: Ubuntu 14.04 LTS PHP 5.5 MySQL Laravel 5.0 Nginx 参考文章:Ubuntu 14.04 上使用 Nginx 部署 Laravel ...

  3. C#学习日志 day 3 ------ 基本语句示例

    写c#首先需要知道的就是数据类型,这里是所有c#中的所有数据类型以及说明.

  4. codeforces 633C. Spy Syndrome 2 hash

    题目链接 C. Spy Syndrome 2 time limit per test 2 seconds memory limit per test 256 megabytes input stand ...

  5. hdu 4292 Food 网络流

    题目链接 给你f种食物, 以及每种食物的个数, d种饮料, 以及个数, n个人, 以及每个人可以接受的食物种类和饮料种类. 每个人必须得到一种食物和一种饮料. 问最后得到满足的人的个数. 因为一个人只 ...

  6. MySQL mysqlimport 从txt文件中导入数据到mysql数据库

    mysqlimport: 我说这个我们还是先从世界观方法论的高度来理解一下便有更加准确的把握.数据导入不外呼有两个部分 第一部分:目标对象--我们要把数据导给谁(mysqlimport 的目标对象自然 ...

  7. 【转载】Android开源:数据库ORM框架GreenDao学习心得及使用总结

    转载链接:http://www.it165.net/pro/html/201401/9026.html 最近在对开发项目的性能进行优化.由于项目里涉及了大量的缓存处理和数据库运用,需要对数据库进行频繁 ...

  8. C++STL之string (转)

    在学习c++STL中的string,在这里做个笔记,以供自己以后翻阅和初学者参考. 1:string对象的定义和初始化以及读写 string s1;      默认构造函数,s1为空串 string ...

  9. #pragma的用法

    在所有的预处理指令中,#Pragma   指令可能是最复杂的了,它的作用是设定编译器的状态或者是指示编译器完成一些特定的动作.#pragma指令对每个编译器给出了一个方法,在保持与C和 C++语言完全 ...

  10. jQuery的hover()方法(笔记)

    因为mouseover和mouseout经常一起写,所以出现了hover() hover(function(){},function(){});第一个参数为鼠标移入运行的函数,第二个为鼠标离开运行的函 ...