应用Docker时需要注意的安全问题

作者:课课家教育更新于： 2017-04-27 10:24:29

　　欢迎大家阅读本篇文章，本篇文章讲述了应用Docker时需要注意的安全问题，本篇文章纯干货，文中有许多的小细节，所以请大家仔细阅读本篇文章哦~

     通过阅读网上帖子以及浏览相关新闻，大家可能会产生一种先入为主的印象，即Docker天生安全性薄弱且尚不足以被直接引入生产环境。不过实际情况是，虽然我们需要对容器安全性加以高度关注，但只要使用得当，其完全可以成为一套远优于单独使用虚拟机或者裸机的安全、高效生产系统。

　　要安全地使用Docker方案，大家首先需要了解其面对的潜在安全问题，并掌握能够对基于容器之系统加以切实保护的各类主要工具与技术。

　　大家还需要随时牢记以下五个问题，并在利用Docker承载关键性任务应用程序的整个流程当中秉承这种谨慎的态度。

　　内核漏洞：

　　与虚拟机系统不同，全部容器及其主机使用的都是同一套共享内核，因此该内核中存在的任何安全漏洞都有可能造成巨大影响。如果某套容器系统导致内核崩溃，那么这反过来又会造成整台主机上的全部容器毁于一旦。在虚拟机当中，情况则要好得多：攻击者必须借道虚拟机内核与虚拟机管理程序之后，才有可能真正接触到主机内核。

　　拒绝服务攻击：

　　所有容器都共享同样的内核资源。如果某套容器能够以独占方式访问某些资源——包括内存以及用户ID等其它更为抽象化的资源——那么与其处于同一台主机上的其它容器则很可能因资源匮乏而无法正常运转。这正是拒绝服务攻击(简称DoS)的产生原理，即合法用户无法对部分或者全部系统进行访问。

　　容器突破：

　　能够访问某一容器的攻击者在原则上应该无法借此访问到其它容器或者主机。在默认情况下，用户并不具备命名空间，因此游离于容器之外的任何进程都将在主机之上获得与容器内相同的执行权限; 而如果大家在容器内拥有root权限，那么在主机上亦将具备root身份。这意味着大家需要对这种潜在的权限提升攻击做好准备——这类攻击意味着用户往往通过应用程序代码中需要配合额外权限的bug实现权限提升，从而使攻击者获得root或者其它级别的访问与操纵能力。考虑到容器技术目前仍处于早期发展阶段，因此我们在规划自己的安全体系时，必须要将这种容器突破状况考虑在内。

　　含毒镜像：

　　那么我们要如何判断自己使用的镜像是否安全、是否存在篡改或者其宣称的来源是否可靠?如果攻击者诱导大家运行由其精心设计的镜像，那么各位的主机与数据都将处于威胁之下。同样的，大家还需要确保自己运行的镜像为最新版本，且其中不包含任何存在已知安全漏洞的软件版本。

　　违规之秘：

　　当容器面向某数据库或者服务发起访问时，其往往需要某种秘密因素加以配合，例如API密钥或者用户名加密码。能够获取这些秘密因素的攻击者自然会将触手伸向对应服务。这类问题在微服务架构当中往往更为严重，因为在此类环境内各容器会频繁中止与启动，因此受到的威胁远高于一般而言运行周期更长且数据较少的虚拟机系统。

　　Docker历史沿革：

　　Docker 是 PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎，源代码托管在 Github 上, 基于 go语言并遵从Apache2.0协议开源。

　　Docker自2013年以来非常火热，无论是从 github 上的代码活跃度，还是 Redhat在RHEL6.5中集成对Docker的支持, 就连 Google 的 Compute Engine 也支持 docker 在其之上运行。

　　一款开源软件能否在商业上成功，很大程度上依赖三件事 - 成功的 user case, 活跃的社区和一个好故事。 dotCloud 自家的 PaaS 产品建立在 docker之上，长期维护且有大量的用户，社区也十分活跃。

　　面对上述几个问题，docker设想是交付运行环境如同海运，OS如同一个货轮，每一个在OS基础上的软件都如同一个集装箱，用户可以通过标准化手段自由组装运行环境，同时集装箱的内容可以由用户自定义，也可以由专业人员制造。这样，交付一个软件，就是一系列标准化组件的集合的交付，如同乐高积木，用户只需要选择合适的积木组合，并且在最顶端署上自己的名字(最后个标准化组件是用户的app)。这也就是基于docker的PaaS产品的原型

      小结：Docker还处于快速地发展之中。每过一个月，再看看Docker，你都会惊喜的发现它在好多方面又已经变得不同了。这也是Docker的一大优势：一个活跃的、快速进化的社区。在使用过程中，你可能会碰到一些问题。但面对这些问题，要么你能很容易地找到回答，要么，会在不久的将来得到解决。当然如果大家还想要了解更多相关方面的详细内容的话呢，请登录课课家教育平台咨询哟~