当前位置:虚拟化行业动态 → 正文

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

责任编辑:editor005 作者:Jim O'Reilly |来源:企业网D1Net  2017-02-10 14:19:15 本文摘自: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提供的功能。那时,我们可以预计组织会迁移到更简化的裸金属容器部署中。还存在更进一步的挑战,比如将软件定义的基础设施纳入容器生态系统中。从安全角度看容器和虚拟机是平等的,但在部署效率上容器要远远超过虚拟机。

关键字:早期评估SUID

本文摘自:TechTarget中国

x 预测潜风险:加强容器保护 扫一扫
分享本文到朋友圈
当前位置:虚拟化行业动态 → 正文

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

责任编辑:editor005 作者:Jim O'Reilly |来源:企业网D1Net  2017-02-10 14:19:15 本文摘自: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提供的功能。那时,我们可以预计组织会迁移到更简化的裸金属容器部署中。还存在更进一步的挑战,比如将软件定义的基础设施纳入容器生态系统中。从安全角度看容器和虚拟机是平等的,但在部署效率上容器要远远超过虚拟机。

关键字:早期评估SUID

本文摘自:TechTarget中国

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^