Docker的安全隐患主要集中在三个方面，分别是内核、服务进程和镜像。
□内核空间隔离与控制不完善
如何有效地禁止容器访问主机或者其他容器的系统文件在生产环境中非常重要，而这点主要与内核namespace、cgroup成熟度以及docker本身实现有关。
namespace至早在2008年就开始在生产环境中使用，并被各种容器实现集成，比如OpenVZ、LXC等；cgroup也在2006年就被推广，在各种企业环境应用中也被广泛使用。但这并不代表它们已经是完善的了，尤其在OpenSSL爆出HeartBleed漏洞之后，企业在开源软件的使用上更加谨慎。
Docker作为用户空间程序，其实现主要依靠前两者，这也就将安全问题一定程度上转移至内核实现和用户使用了。比如，namespace中并没有隔离全部子文件系统，主机的中断、总线、内核模块子文件系统包括/sys、/proc/｛sys，irq，sysrq-trigger，bus｝等仍暴露于容器中，这样就留下了潜在的安全威胁。在cgroup隔离问题上，需要用户具有一定的经验对容器的资源使用进行仔细划分，否则也极易影响其他容器进程中应用的健康。
□Docker daemon进程（Docker主机）服务易被攻击或恶意使用
目前运行docker daemon进程需要root权限，由于它同时提供REST API给用户，这就需要服务端在接收客户端请求时需要仔细检查传入的参数。Docker的早期版本（0.5.2之前），它的服务进程在127.0.0.1的TCP端口监听（目前Windows中的Docker服务端仍然在tcp：//IP：port上监听），这一定程度上引入了第三方攻击的风险。其后的版本默认使用了UNIX套接字提供服务，则能够有效阻止此类攻击。(www.xing528.com)
为了减少此类风险，我们一般对docker daemon提供的API进行封装，比如将客户端请求先交由代理程序处理，再转发至在本地UNIX套接字监听的Docker daemon服务端，同时在代理程序中实现请求的排队、审核等“缓冲”策略。这样的实现已经被虚拟化服务证实是有效可行的，在容器服务中具有一定参考意义。
□Docker Registry镜像缺乏可信验证
由于Docker Hub是一个公有镜像库，所以当我们从其中下载镜像时要留心某些“恶意”镜像。Docker很早便意识到了这点，所以他们提供了Docker Notary和Docker Trusted Registry（DTR）分别用于镜像签名、发布、存储过程中的安全保证。当然，此类安全问题在私有云环境中有时难以避免，读者可以在实际使用时建立适当的镜像管理制度予以防范和溯源，尽量减少“恶意”镜像的存在。
【注释】
[1]Namespace in Action，HTTP：//lwn.net/Articles/531114/.
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
