当面对容器技术时，安全性往往是人们最为关注的问题。开发人员喜爱容器，某些运维人员也对其赞赏有加。但如果使用不当，其是否会带来安全隐患？我们热爱容器方案的各类天然特性，但在安全性方面其是否会同时成为一种短板？在今天的文章中，我希望带领大家了解一些围绕容器进行的深度安全保障机制。由于本文专门针对容器系统，因此我不会拿出篇幅讨论主机节点或者通过禁用Linux守护进程减少攻击面之类的议题。
只读容器系统（Docker 1.5）首先，我们可以运行只读容器系统。通过指定--read-only，容器的rootfs将以只读方式启动，这样容器当中的任意进程都无法对容器本身进行写入操作。这意味着当我们由于应用中存在安全漏洞而出现文件上传行为时，其会由于容器rootfs的只读属性而被阻断。这同时也会阻止应用向rootfs内写入日志记录，因此我们可能需要利用远程日志记录机制或者指定分卷来完成相关写入操作。
使用方法（docs）：
用户名空间（Experimental）
很多人都在热切期盼着这项功能。目前，拥有容器的root权限意味着我们在主机上同样拥有root权限。如果我们能够在自己的容器当中实现/bin，那么也同样能够将任何预期内容添加进来，甚至彻底控制主机系统。而随着user-namespace的引入，大家将能够在保证用户在容器内拥有root权限的前提下，利用uid:gid保证对应的用户/群组在容器之外处于非高权限状态。作为第一阶段，我们现在可以对每个域实例中的root进行重新映射。作为发展的下一阶段，我们可能会进行全局映射以及每容器映射，不过这样的能力是否必要仍在讨论当中。
使用方法（docs）：
Seccomp（Git主分支）
在命名空间的帮助下，我们已经能够实现权限分享。但除此之外，我们还需要对容器当中能够运行的具体负载进行控制。这时就需要依靠seccomp了——所谓seccomp，其实就是安全计算模式的缩写。它允许大家对系统调用进行筛选，这样我们就能够为应用程序定义其需要的系统调用，并拒绝其它一切不必要的调用行为。下面例举一个简短的socket.json实例：
{"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"name": "socket",
"action": "SCMP_ACT_ERRNO"
}
]
}
其运行结果将如下所示：
root@54fd6641a219:/# nc -l 555
nc: Operation not permitted
Nautilus项目
目前Docker生态系统中的一项重要功能缺失就是对镜像内容的检查。此前曾有文章指出，当下Docker hub中超过30%的官方镜像存在着常见安全漏洞，这一消息旋即引起轩然大波。Docker方面立即着手处理，而且现在各被发布在Docker hub中的官方镜像在正式推出前都需要进行扫描。在本届Dockercon欧洲大会上，Docker方面公布了Nautilus项目，这是一项官方提供的镜像扫描服务，能够让我们更为轻松地构建并使用高完整性内容。
目前关于Nautilus项目还没有太多官方说明，不过我们了解到其运行在后台当中，而且Docker方面表示他们已经借此对超过7400万条pull进行了保护。最近，他们还发起了一项调查，征求用户们的实际使用需求。在这里我只能先为大家提供一些假设。首先，Docker方面表示该项目能够：
保障镜像安全
实现组件库存/许可管理
实现镜像优化
实现基础性功能测试
以下是几项可能即将实现的特性：
通过使用AppArmor，大家可以借助配置文件对功能进行限制。配置文件可以实现极为出色的控制粒度，但很多人并不希望把时间耗费在编写配置文件方面。考虑到这类配置文件对Docker容器运行的重要意义，Jessie Frazelle作为Docker的核心维护者之一，创造了bane以简化配置文件的编写难度。它能够使用toml输入文件，并生成及安装AppArmor配置文件。该配置文件随后可以被用于运行Docker容器，且采用与之前相同的语法：
docker run -d --security-opt="apparmor:name_of_profile" -p 80:80 nginx Docker安全状况这一切都能够帮助我们实现容器安全保障，当然Docker自身也在努力降低相关方案的执行难度。这意味着如果大家希望了解与本议题相关的各类细节信息，可以点击此处查看GitHub的对应分区并获取各类最新建议。
更多Docker相关教程见以下内容：