Docker作为应用容器中的实现方式，在近几年得到飞速的发展，随着大量国内外企业将其应用到生产环境中，docker的安全防护也成了一个不容忽视的问题。docker的优点有很多，但由于其诞生的目的就是便于持续的集成和快速部署，尽量减少中间环节，这也为其安全控制带来难度。
那么docker安全吗，很明显答案是否定的，因为从技术上来说不存在绝对安全。其实对docker容器安全质疑最大的一点就是其隔离的彻底性，与其对比就是当前成熟的虚拟机（VM）技术。相对于VM，docker容器只是对进程和文件进行虚拟化，而VM做到了OS级别的虚拟化。从这个角度看VM的隔离性确实要好于docker容器，也就是说对宿主机的安全影响VM要远远小于docker，但换个角度看，这也恰恰正是docker的一个优点：轻量级，高效以及易移植。所以，安全和易用永远存在在一个平衡点。本文既在此探讨关于docker作为开发docker容器时的安全方面的几点建议。1.Docker主机，应用：及时的安全更新
docker安全从主机开始启动时，其中的容器共享操作系统内核，如果主机受到威胁，则所有进程都容易受到攻击。在docker容器内运行的进程看上去似乎是在隔离的Linux主机上运行，但实际上，它们只是共享主机内的“namespaced”进程。 所以在运行docker容器前，需要做到的是使主机操作系统得到正确的修补和更新。 同样，在容器中运行的进程应更新到最新的安全版本，并且在容器启动时应用采用最新的安全方案。
2.Docker运行安全：知晓你的容器中code的内容
在构建docker容器镜像时，需要确切知道是每个层中包含的是什么。 但是，仅在构建容器时这样做是不够的。 还必须确保第三方供应商安装的容器不会在运行时下载和运行任何内容。 docker容器运行的所有内容必须公布并将其包含在静态容器镜像中。 这对于第三方供应商容器尤其重要。 为了简化安装，某些辅助工具会部署一个最小的代理，然后在运行时下载其他语言的进行代理。 所以，对于这种在运行时的额外下载其他代码进行运行的应该及时停止，以免遭受不必要的安全威胁。
3.Docker镜像的真实性：你真的信任镜像源？
就像我们不会从任何随意从网上下载并运行来源不明的软件一样，在运行容器镜像之前，我们必须知道即将启动的容器镜像的来源和注册表。
Docker Store相较于Docker Hub是一个更值得信赖的market。 与任何人都可以推送容器镜像到Docker Hub的不同，Docker Store托管着那些有一定信誉保证的开发者的容器。 docker也对这些docker容器镜像进行了漏洞测试。 而docker镜像本身提供的对它自己的来源和验证。在Docker Store中，也可以查询获得该docker容器镜像的最新的数字签名版本。
从设计上来说，docker在构建时具有可观的安全性。 但是重要的是，永远不要放松警惕，尤其是在运行来自第三方供应商的docker容器时。
4.限制Resource的使用率：避免互相干扰
由于docker容器是轻量级进程，因此docker可以运行比虚拟机更多的容器。 这种增加运行的密度是有益的，因为它增加了主机资源的利用率，并控制了优化总体运行的成本，但这也意味着更多的进程正在争用主机资源。
为了减少诸如拒绝服务攻击之类的漏洞的威胁以及由于其他进程干扰造成的性能影响，我们可以通过对容器管理的框架（如Kubernetes或Swarm）来限制各个容器可以使用的系统资源。
AppDynamics亦能全面监视主机上所有受监视容器消耗的资源。 通过在AppDynamics中设置的阈值和警报来主动采取措施，以便在任何docker容器接近其限制时收到警报。
5.在Super-Privileged模式下运行？
如果即使遵循上述四个建议，但仍以Super-Privileged模式运行你的（或第三方）docker容器，则实际上是在拧紧窗户，却将前门敞开。在Super-Privileged模式运行的容器打破了基本的隔离和封闭周围的容器的原则，docker容器内的root拥有真正的root权限。普通容器的root只是外部的一个普通用户权限，privileged启动的容器，可以看到很多host上的设备，并且可以执行mount，甚至允许你在docker容器中启动docker容器。这样的容器将大大增加了威胁，潜在地危害了整个数据中心或VPC环境。
不过在默认情况下，docker不会以Super-Privileged模式运行容器，所以必须明确授予这些权限，只有在docker容器需要访问某些受保护资源的情况下才可以这么做。
结尾
docker在构建时具有适当的安全性，根据上述几点建议希望能对docker安全防护有一定了解，但要明确的是，永远不要放松警惕。