机房360首页
当前位置:首页 » 虚拟化资讯 » 容器VS虚拟化之安全性

容器VS虚拟化之安全性

来源:机房360 作者:娟子 更新时间:2014/11/9 19:58:23

摘要:多数人都认为容器不安全,但又不舍放弃其带来的高性能和便捷性。本文作者认为Docker其实已经提供了一种安全模式,并且能和SeLinux、AppArmor等所有Linux的安全方案搭配使用,只是很多人没有用好而已。

  提到容器的安全性,多数人都说它不够安全,但又不舍放弃其带来的高性能和便捷性。本文作者认为Docker其实已经提供了一种安全模式,并且能和SeLinux、AppArmor等所有Linux的安全方案搭配使用,只是很多人没有用好而已。作者通过将裸机、VMs和Container比作是建筑、公寓和私人房间,说明了这个问题。当然,从另一个角度来说,作者只考虑了单租户的问题,对多租户的情境,Container的安全性依旧不够。以下问原文:

  自去年开始,Linux容器就一直处于技术炒作的最前沿,各种关于容器安全的讨论也随处可见。在大部分发表的讨论、文章和博客中,不管需要与否,与VMs的对比都不可避免。故事的真相更接近于“containers always”及“VMs sometimes”。 当然,也存在一些用户,在使用Docker后开始重新评估VMs。而在大部分情况下,用户更加偏向于性能而不是安全——单租户环境中,在使用VM生命周期管理方式的同时,避免虚拟化的开销无疑更加令人向往。

  然而,对于那些依赖VMs实现安全解决方案,Docker并不是替代,而是补充。

  通常情况下,我更愿意将裸机、VMs和Container比作是建筑、公寓和私人房间。Linux容器可以存在于VM中,同样它们也可以直接运行在裸机上。现实生活中可能存在几个朋友共享一个公寓,他们分别使用自己的私人房间。但是毫无疑问,这和每个人拥有自己的公寓并不一样。如果你想和几个朋友共享一个公寓,那么这些人必须是你完全可信的。即使这样,这种安全只在一定的条件下可以,同时是有限度的。

  我和妻子结婚已经12年,有两个孩子和我们生活在一起。我和妻子住在一个房间,而孩子住在另一间,还有第三个房间,是我的家庭办公室。将孩子们放在一个单独的公寓并没有太大意义,就像在自己VM上增加一个OpenSSH守护进程将之与应用程序分离一样。

  孩子们有各自的私人房间,是未来让他们不会赖在父母的床上,但结果却差强人意(如果为3岁大的女儿准备自己的公寓,必然会触发一个CPS应用)。

  我的家庭办公室是个禁止通行区域,就如我给这个房间配备了定制的防火墙,但是我的孩子仍然会进来,虽然不是经常。即使两岁大的孩子都清楚那个是父亲的空间,并且尊重这个设定。

  容器就像是私人房间,在保护隐私方面是无价的——出于某些原因,在同一台主机或者VM上经常需要混搭多个进程。而在容器环境下,这些进程已经被隔离了,VMs带来的安全效益已不复存在。

  这种容器之间松散的隔离并不是bug,而是一种有用的特性。我们假定容器中运行的进程运行在同一个VM上,那么在这些进程间实施严格、更细粒度的访问控制是一件好事。

  实际情况下,即使是在一个运行单进程的主机上,运行容器也有助于你的安全防护。谁能保证以后我们不会运行任何通用进程?比如通常主机上都会运行的syslogd、sshd等。这显然不可能,在这里,我们可以假设有一个VM会直接加载一个网络服务器作为它的初始化进程(PID 1)。

  那么这个进程可能会造成什么样的结果?它可以做什么?它是否可以发送原始网络框架?是否可以提升到root权限?既然系统上存在setuid-root,它是否可以被提升权限?如果可以提升,那么它可以做什么?它是否可以进行DAC重写,或者挂载文件系统,亦或是做其它只有root权限用户才可以进行的事情?

  肯定的是,SeLinux可以被用于保护你的进程。但是相信不少DevOps工程师都将SELinux禁用了,并且没有多少人重写过自己的SELinux策略,甚至读过SeLinux策略的人都很少。时至今日,当下的Linux系统中又会有多少使用了SeLinux作为Docker的默认安全策略呢?这里的阻碍又是什么?

  不错,你的应用程序可以放弃这些特权,但是你需要的应用程序及开发者做一些正确的事情。当然,你还可以选择使用一个包装盒,也就是Docker做的事情。

  换个角度说:即便使用了VM,也不意味着你可以在主机上运行“chmod -R 777 /”。你的系统提供了进程所需要的安全政策,但是你可能并没有使用它们。Docker就是提供了这个功能的工具,在最大程度上的开箱即用。

  毫无疑问,不管是从工具的角度还是文化的角度来说,上述问题正是DevOps成败的关键。而对于许多机构来说,“DevOps”通常是“soft ops”(软件层面上的Ops)。对比以往,开发者在建立和部署应用程序时有了更多的特权,尤其是在一个VM内时。这也导致了关注点的分离,通常hard-ops(硬件Ops) 工程师只负责硬件和网络基础设施的健康。而对于那些运行AWS或者GCE上的服务,更是将hard-ops外包给了Google和AWS。

  hard-ops工程师,传统系统管理员,以及安全工程师,他们过去通常做的事情是应用程序部署工作,以及帮助评估安全问题。在有些机构,他们可能仍然从事这样的事情。但毫无疑问的是,开发者使用self-provisioning-in-a-bubble模式的机构数量正在增加。

  不幸的是,在DevSecOps(或者说是SecDevOps)上并没有太大的进步。同时,随着DevOps向“No Ops”的倾斜,人们对安全上的关注可能在日渐减弱。

  Docker作为一个DevOps工具,通过为用户提供一种安全模型,同时也让模型更容易及便捷的被调整,而在改变这种现状。Docker将安全切实的转交到开发者手中,让他们避免搬起石头砸自己的脚。

  使用Docker,用户将默认获得严谨的功能集,而获得这个能力仅仅需要调整一些命令行参数。同时,对比以往阅读Linux系统调用手册后再胆战心惊的调试,你只需要在运行时设置一个简单的标记(或许在将来,这个操作可以通过Dockerfile更便捷的完成)。

  容器安全肯定不会优于一个使用sys_setcap()做良好安全保障的应用程序,但是对于容器来说,它不与任何其他最佳实践冲突。它与VMs并不矛盾,可以良好的配合运行。同时,它与SeLinux或者AppArmor也不冲突,同样可以良好的搭配使用。事实上,使用之后你会发现,所有Linux中存在的安全方案都可以通过Docker进行。


责任编辑:娟子编辑

机房360微信公众号订阅
扫一扫,订阅更多数据中心资讯

本文地址:http://www.jifang360.com/news/2014119/n827462880.html 网友评论: 阅读次数:
版权声明:凡本站原创文章,未经授权,禁止转载,否则追究法律责任。
相关评论
正在加载评论列表...
评论表单加载中...
  • 我要分享
推荐图片