这一年，Docker在安全性上做了哪些努力？进展如何？

当面对容器技术时，安全性往往是人们最为关注的问题。开发人员喜爱容器，某些运维人员也对其赞赏有加。但如果使用不当，其是否会带来安全隐患？我们热爱容 器方案的各类天然特性，但在安全性方面其是否会同时成为一种短板？在今天的文章中，我希望带领大家了解一些围绕容器进行的深度安全保障机制。由于本文专门 针对容器系统，因此我不会拿出篇幅讨论主机节点或者通过禁用Linux守护进程减少攻击面之类的议题。

只读容器系统（Docker 1.5）

首先，我们可以运行只读容器系统。通过指定--read-only， 容器的rootfs将以只读方式启动，这样容器当中的任意进程都无法对容器本身进行写入操作。这意味着当我们由于应用中存在安全漏洞而出现文件上传行为 时，其会由于容器rootfs的只读属性而被阻断。这同时也会阻止应用向rootfs内写入日志记录，因此我们可能需要利用远程日志记录机制或者指定分卷 来完成相关写入操作。

使用方法（docs）：

User-namespaces （试验阶段）

很多人都在热切期盼着这项功能。目前，拥有容器的root权限意味着我们在主机上同样拥 有root权限。如果我们能够在自己的容器当中实现/bin，那么也同样能够将任何预期内容添加进来，甚至彻底控制主机系统。而随着user- namespace的引入，大家将能够在保证用户在容器内拥有root权限的前提下，利用uid:gid保证对应的用户/群组在容器之外处于非高权限状 态。作为第一阶段，我们现在可以对每个域实例中的root进行重新映射。作为发展的下一阶段，我们可能会进行全局映射以及每容器映射，不过这样的能力是否 必要仍在讨论当中。

使用方法（docs）：

Seccomp（Git主分支）

在命名空间的帮助下，我们已经能够实现权限分享。但除此之外，我们还需要对容器当中能够运行的具体负载 进行控制。这时就需要依靠seccomp了——所谓seccomp，其实就是安全计算模式的缩写。它允许大家对系统调用进行筛选，这样我们就能够为应用程 序定义其需要的系统调用，并拒绝其它一切不必要的调用行为。下面例举一个简短的socket.json实例：

其运行结果将如下所示：

Nautilus项目

目前Docker生态系统中的一项重要功能缺失就是对镜像内容的检查。此前曾有文章指出，当下Docker Hub中超过30%的官方镜像存在着常见安全漏洞，这一消息旋即引起轩然大波。Docker方面立即着手处理，而且现在各被发布在Docker Hub中的官方镜像在正式推出前都需要进行扫描。在本届Dockercon欧洲大会上，Docker方面公布了Nautilus项目，这是一项官方提供的 镜像扫描服务，能够让我们更为轻松地构建并使用高完整性内容。

目前关于Nautilus项目还没有太多官方说明，不过我们了解到其运行在后台当中，而且Docker方面表示他们已经借此对超过7400万条 pull进行了保护。最近，他们还发起了一项调查，征求用户们的实际使用需求。在这里我只能先为大家提供一些假设。首先，Docker方面表示该项目能 够：

• 保障镜像安全

• 实现组件库存/许可管理

• 实现镜像优化

• 实现基础性功能测试

以下是几项可能即将实现的特性：

• 以内部方式运行Nautilus

• 针对单一镜像或者单一部署节点进行计费

  

AppArmor配置文件

通过使用AppArmor，大家可以借助配置文件对功能进行限制。配置文件可以实现极为出色的控制粒 度，但很多人并不希望把时间耗费在编写配置文件方面。考虑到这类配置文件对Docker容器运行的重要意义，Jessie Frazelle作为Docker的核心维护者之一，创造了bane以简化配置文件的编写难度。它能够使用toml输入文件，并生成及安装 AppArmor配置文件。该配置文件随后可以被用于运行Docker容器，且采用与之前相同的语法：

Docker安全状况

这一切都能够帮助我们实现容器安全保障，当然Docker自身也在努力降低相关方案的执行难度。这意味着如果大家希望了解与本议题相关的各类细节信息，可以点击此处查看GitHub的对应分区并获取各类最新建议。

原文链接：Security Is Maturing In The Docker Ecosystem

转载自：dockone