原文译自:

这篇文章基于我今年在DockerCon一个讲座,它将讨论我们当前听到的Docker容器的安全问题.

容器并不"包容"

我听到也读到很多假定Docker容器是应用沙盒的观点--这意味着他们能够在他们的系统上使用有根权限的Docker来执行随意的程序. 他们相信Docker容器将会保护他们的主机系统.

• 我听到人们说Docker容器就像在VMs/KVM执行程序一样安全
• 我知道人们在随意的下载Docker镜像然后在他们的主机上执行
• 我甚至看到PaaSserver(不是OpenShift)同意用户上传他们自己的镜像执行在多租户系统上
• 我有一个同事说道: Docker就是从网上下载随意的代码并以root模式执行

"你要来我的客厅吗", 蜘蛛对蝴蝶说道.

停止这样的设为Docker和Linux会保护你免于恶意软件的想法吧!

你在乎吗?

假设你不在一个多租户系统里执行Docker,而且你对执行在容器里的服务使用良好的安全策略,那你基本上不须要操心.只假定执行在容器里的特权进程就像在容器外的特权进程一样.

一些人错误的觉得容器是一种比虚拟机更好更快的方式,但从安全的角度来看,容器更脆弱,这点我将在文章的后面说明.

假设你相信我说的,Docker容器应该被视作"容器服务"-这意味着你要把执行Apache的容器看作在你的Host系统上执行的Apache服务,这就是说你要:

• 尽快的减少特权
• 尽可能以非root模式执行你的服务
• 将容器里的root模式视为容器外的root模式

眼下我们正在通用规范中告诉人们把容器的特权进程当在容器外的特权进程.

不要在你的系统里执行随意的Docker镜像,我从很多方面看到Docker容器革命类似于1999年的Linux革命,那时当一个管理员听到一个新的非常酷的Linux服务时,他们会:

• 去rpmfind.net和其它一些站点上去搜索包
• 下载这些包
• 通过RPM或make install来安装
• 以管理者模式运行

会出什么问题?

两周后管理员听到一个zlib的脆弱性问题并不得不指出( 他们希望并祈祷不是), 软件是不安全的!

这就是Red Hat发行版和其它一些值得信赖的第三方介入并解救他们的时刻, Red Hat的企业版Linux给管理员提供了:

• 一个提供下载的安全的repository
• 安全的升级来修复问题
• 发现问题并修复的团队
• 管理/维护/安全增强的project师团队
• 通用的认证标准来检查OS的安全性问题

仅仅执行从可信赖组织获得的容器,我相信你应该继续从同样的人那边获得代码/包,就像你曾经做的一样.假设代码不从那边来, 不要相信容器技术会保护你的主机.

所以问题是什么? 为什么容器并不"包容"?

最大的问题就是Linux的一切都不是命名空间 (namespaced). 如今, Docker使用5个命名空间来改变系统的进程: 进程, 网络, Mount, 主机名,共享内存.

尽管有给用户一定的安全级别, 但无法像KVM实施全面的安全保护. 在KVM环境下进程不直接和主机的内核交互.它们也不訪问内核的文件系统如/sys和/sys/fs, /proc/*

设备结点是用于和VMs 内核交互的,而不是主机.因此, 想要越过VM来扩展特权级别, 进程要去攻击VM内核,找到HyperVisor的弱点,打破SELinux的控制(sVirt),终于攻击主机的内核.

当你执行在一个容器里时,你就已经直接能够和主机的内核打交道了.

没有被当成命名空间的基本的内核子系统如:

• SELinux
• Cgroups
• /sys下的文件系统
• /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus

没有被当成命名空间的设备:

• /dev/mem
• /dev/sd* 文件系统设备
• 内核模块

假设通过一个特权进程对以上的某个模块通信或攻击的话,你就拥有了整个系统.