李光成 译 分布式实验室
Docker容器已经成为开发者工具箱中非常重要的工具，这项技术的被接受程度也已经非常高了。到今天为止，Docker已经有超过了20亿次的下载，这对于2015年4月的3亿次的下载来讲是一次飞速的发展。有些组织刚刚开始使用这项技术，而有的公司则已经深入研究了一段时间，他们都成为这迅速增长的部署的来源。
容器使得你可以从更小的结构单元开始构建复杂的应用, 每个结构单元执行一个单独的功能。这种架构也被称之为微服务，非常适合持续部署系统，当某个微服务的组件被在线升级时不会影响到其它服务的运行。
但是这种迅速成长的浪潮让很多企业安全专家担忧，来自Red Hat的Dan Walsh曾经写过一些非常好的文章来解释为什么容器无法包容。虽然容器提供了系统资源的隔离例如内存和CPU，但是运行在同一个主机上的所有容器共享一个操作系统，某个容器的安全问题很有可能被通过共享的内核而影响其它的容器。
虽然这些担忧是合理的，但是还是可控的。让我们来看一下如何利用Docker容器的内在结构来防护容器化的应用。
Docker——隔离状态的能力
Docker容器是从静态的镜像构建的，镜像由不同的层次构成。这些层次可以被不同的镜像复用。例如，Ubuntu的基础层可以出现NGNIX容器中，也会出现在Mongo DB的容器中。
当一个容器镜像被实例化之后，就成为了一个容器。在一个Docker容器中，这些层次组成了一个统一的容器文件系统。每一层被实例化为只读，在其上会有一个可读写的层次来记录容器运行过程中对文件系统进行的修改。
当一个容器退出时，如果用户没有执行“docker commit”，则读写层将会消失，没有任何的状态变化被记录，镜像将保持不变。如果用户执行了“docker commit”，这个读写层将会被加到原有的镜像上并生成一个新的镜像（译者注：原有镜像保持不变）。利用这种方法，每个 “docker –commit” 以一种可控的增量方式记录了连续的变化和容器状态的变化。你不但可以容易的回退到一个先前的状态，这对可追溯性、可管理性和鉴证也是非常有用的。
这种显式的将状态变化限制在读写层是对安全性非常有用的功能。首先，这保证了大部分代码在只读模式下运行，这意味着运行过程中的任何不良情况都无法持久，除非你显式的commit这些变化。其次，这给了你一个机会去专注对读写层的监控。
但是，无状态容器的一个最重要的作用是用户可以更容易的获得容器的基线行为模型，如果观测到的运行时行为跟基线不同，你就知道这里面存有潜在的问题。
这解决了风险和异常检测中最大的问题，就是开发一个有用的基线来标识“正常”。你一旦有了这样一个基线并可以正确检测异常时，你就可以使你的容器能够控制和抵御潜在的攻击。
在生产中使用容器
Docker容器提供的能力可以以只读方式运行大部分应用，并可以将状态变化隔离到某个可管理的模块中。这带来了在安全方面进行创新的机会,但这要求你深入的研究和利用容器架构的内在特性。
一个数字媒体公司这样做了，这个公司在云中运行了大量的服务提供给消费者和商业用户。开发团队一年前开始使用Docker，现在这个公司已经在Docker里运行了大部分的服务。
安全团队对所有的容器镜像进行了安全检查，成功的去掉了构建不佳和违法公司政策的镜像。接下来，他们制定了一个规则，容器需要以只读方式运行。只有个别特例的应用可以commit运行时变化，而这些应用会被认真的记录和追溯。
这个公司正处在将其应用改造成微服务和容器的征途上，他们的目前经验，除了这是一个更加有效的应用架构外，安全团队也说服了他们，这种新的架构使他们为未来更多的变化做好准备，问题能够更容易的被检测和处理。
本文为翻译文章，点击阅读原文链接可查看原文。
