预测潜风险:加强容器保护

日期: 2017-02-09 作者:Jim O'Reilly翻译:张冀川 来源:TechTarget中国 英文

容器是IT行业最热门的软件话题。共享虚拟机通用部分——操作系统、管理工具乃至应用,大大减少了镜像消耗的内存资源,同时减少了加载相同代码的众多副本所需占用的网络带宽。 容器的实现方式能够节省大量的资源。早期评估容器支持的实例数是传统基于hypervisor方式的3到5倍,结果证明是合理的。

在某些情况下,比如虚拟桌面基础设施市场,容器支持的能力甚至更好。创建、部署容器所需要的时间只占创建、部署虚拟机的很小一部分。 容器价格要比hypervisor虚拟化低很多,但容器是一门新技术,技术不成熟一定会涉及到一些令人痛苦的教训,之前我们采用hypervisor虚拟化时已经有所体会。尽管很多组织在某种程度上……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

容器是IT行业最热门的软件话题。共享虚拟机通用部分——操作系统、管理工具乃至应用,大大减少了镜像消耗的内存资源,同时减少了加载相同代码的众多副本所需占用的网络带宽。

容器的实现方式能够节省大量的资源。早期评估容器支持的实例数是传统基于hypervisor方式的3到5倍,结果证明是合理的。在某些情况下,比如虚拟桌面基础设施市场,容器支持的能力甚至更好。创建、部署容器所需要的时间只占创建、部署虚拟机的很小一部分。

容器价格要比hypervisor虚拟化低很多,但容器是一门新技术,技术不成熟一定会涉及到一些令人痛苦的教训,之前我们采用hypervisor虚拟化时已经有所体会。尽管很多组织在某种程度上使用了容器,但在谈到确保容器安全性时,大多数组织承认存在严重的恐惧。

数据安全隐忧

最核心的问题是多租户保护。Hypervisor已经推出十多年,更重要的是已经经历了几个CPU周期。Intel以及AMD已经增加了对应的功能避免hypervisor出现跨内存攻击。

这些特性保护没有本地存储的系统,但用于加速应用的本地实例存储的出现意味着面临着数据被删除的风险,尤其是固态硬盘数据可能会暴露在租户之间。Hypervisor厂商灵活应对,将数据块标记为未写入。如果实例尝试读取没有别写入的数据块时,hypervisor会发送全零并保护该数据块中的所有数据。

没有上述保护措施,hypervisor就不全,任何租户都能够访问其他实例中的数据。在一台服务器的所有容器之间共享单个操作系统镜像使硬件内存保护屏障变得无效。

这两个问题可以通过在虚拟机内运行容器缓解。这避免了一台虚拟机内的容器暴露给其他虚拟机,而hypervisor提供了所需要的存储保护。所有主流云以及hypervisor,包括Azure现在都支持容器。

但这一保护措施存在代价。在规模扩张期间,必须在构建容器之前创建虚拟机。容器部署时间是以毫秒衡量的,而虚拟机构建时间是以秒衡量的。即使存在上述限制,但基于虚拟机的容器是一种可行的方式,也是到目前为止最常见的部署方式。部署轻量级hypervisor有大量的工作要做。例如,Intel Clear Containers是一个专为容器构建的hypervisor。此外,它使用内核相同页合并安全地在虚拟机之间共享内存页以减少内存占用。VMware还支持容器—考虑到其在虚拟化的主导地位—这对提升很多用户的使用信心至关重要。

用户访问控制

除跨租户信息泄露外,容器还面临权限升级风险,应用获取root权限就能够控制主机。另一个问题是拒绝服务攻击—或者是bug驱动的问题—所有资源都被单个容器占用了。这些问题在容器环境中更容易出现。例如Docker与主机系统共享命名空间,但在基于hypervisor的系统中不存在这种情况。

为保护容器并减少权限升级攻击,要以普通用户而非root用户运行容器。在Docker中,需要在启动命令中增加-u选项。移除SUID标签能够修复该问题。在容器之间隔离命名空间限制了野蛮应用接管服务器存储空间。控制组可以被用于设置资源限制并阻止吃掉服务器资源的DDos攻击。

镜像中毒

另一个主要的避免攻击的保护措施,尤其是在私有云中,是使用可信任的公共镜像资源库。目前几乎所有的插件都使用众多公共资源库资源构建应用程序。这节省了大量的开发时间及成本,IT预算紧张时这是一项重要的实践。然而大量的恐怖事件比比皆是。即使是高级资源库也有可能传播恶意软件,分析最近发生的一些事件,发现部分代码多年以来一直仍旧隐藏在流行的类库中。

来自受信资源库的代码容易受到病毒入侵的攻击。镜像控制是当前所有环境而不仅仅是容器所面临的一个核心问题。使用支持镜像签名的受信资源库,并在加载镜像时使用这些签名进行验证。有一些服务能够用于签名验证,合理使用这些服务有助于缓解恶意软件渗透。Docker Hub、Quay是两个受信的公共容器注册平台。

另一个问题不是容器特有的,但由于容器所使用的典型的微服务环境使问题变得更加严重,由于用户希望对他们运行的应用插件进行控制,这使得资源库控制有点像把猫赶到一起一样糟糕。对源识别及签名校验进行强制的用户级验证对确保环境安全稳定至关重要。GitHub站点上的Docker安全性测试是一个对众多已知的安全问题进行检查的工具。

自己构建一个合法的镜像库供用户访问可能是最终的实施方式,但缺点在于程序员很难管理而且类库管理员缺乏敏捷性几乎注定类库会被忽略掉。任何资源库必须有非常严密的安全措施限制访问第三方资源库的镜像而且没有写权限。为便利镜像库管理,你可以使用Docker的注册服务器或者CoreOS企业注册库。

校验与加密

对镜像内的应用及操作系统进行版本控制的措施相当脆弱。这同样不仅仅是容器问题,而是容器在快速演变而且当新版本需要强化安全性时Docker倾向于拆除操作代码架构并予以替换。版本控制不合规往往会提供攻击面。

镜像扫描工具可以用于自动校验镜像、文件。Docker提供的镜像扫描工具是Nautilus,CoreOS提供的是Clair。镜像加密问题仍旧没有得到解决。

通常来讲,对容易受到攻击的文件进行更多的加密,受到恶意软件攻击的可能性就更低。对镜像来说,加密应该在镜像代码中保护病毒或者木马攻击,结合签名扫描以及播放列表验证,应该可以阻止恶意软件的攻击。和hypervisor相比,容器具有明显的优势。容器的镜像文件更少,加密、解密时服务器的负载更低。

容器守护进程是另一个脆弱点。守护进程是管理容器的进程,如果遭到破坏,就能够获取系统内的所有信息。限制访问是保护守护进程的第一步。如果守护进程暴露在网络中,那么必须采用加密传输方式。同时使用限定的管理工具进行最基本的Linux配置能够减少攻击平面。

采取上述措施,我们就具备了创建安全容器并构建镜像的基础。在容器运行时提供保护仍旧是一项正在进行中的工作。在监控领域有很多开创性的产品,提供了控制不稳定混合实例的第一步。CAdvisor是一款很不错的用于监控容器的开源工具,而Docker提供了stats命令。这些工具的输出结果需要插入到合适的分析包中比如Splunk或者Sumo Logic的Docker日志分析应用中。通过建立正常运营的基线,由恶意软件而引发的非正常访问都可以被发现并进行补救。

在过去的几年当中容器已经得到了很大的发展。安全环境一定需要建立严格的制度,但很显然容器社区正在引领镜像管理领域。

我们可以预计下一代或之后的CPU会针对容器提供硬件支持,匹配目前针对hypervisor提供的功能。那时,我们可以预计组织会迁移到更简化的裸金属容器部署中。还存在更进一步的挑战,比如将软件定义的基础设施纳入容器生态系统中。从安全角度看容器和虚拟机是平等的,但在部署效率上容器要远远超过虚拟机。

翻译

张冀川
张冀川

TechTarget中国特约专家,任职于某国企信息中心,负责数据中心硬件基础设施及信息系统运维管理工作,对虚拟化及云计算技术有浓厚兴趣,并在工作中积极应用

相关推荐

  • 描绘VMware容器未来蓝图:VIC与Pivotal

    容器技术已经推出几年了,而且其原理很容易理解。容器成本低、运行速度快、易于部署而且承诺提供更大的可扩展性。在容器需求量持续增加期间,VMware开发了自己的容器平台以满足不断增长的需求—vSphere集成容器(VIC)以及Photon Platform。

  • VMware和Pivotal在容器领域达成合作

    Pivotal Container Service将Kubernetes集成到vSphere,同时借助NSX提升安全性,但是这项新服务让我们不得不思考VMware自有容器项目的问题。

  • 起底虚拟机优势

    虚拟机是物理计算机的逻辑表现形式。虚拟机有众多优势,但列举虚拟机的众多优势之前有必要了解下虚拟机是如何创建以及如何工作的。为创建一个虚拟机,先要在物理计算机上安装hypervisor。

  • 主流hypervisor总拥有成本及功能对比

    在众多hypervisor中做出选择可能是管理员要做出的最重要的决定之一。在做出上述决定时,务必牢记要在已经推出市场一段时间的hypervisor中进行选择。