我明白了。我真的。容器让数据中心和云管理员放置一个给定服务器上的服务器实例多出两到三倍比他们在虚拟机中所能做到的还要多。这意味着更少的服务器，也就意味着更少的电力消耗，这就等于——Ka-ching!——减少IT预算支出。有什么不喜欢的呢?
嗯，你看，有个小问题。目前还不清楚容器的安全性有多高，而且对于如何保护它们以及由谁来承担这一责任，肯定也没有多少共识。
作为Libvirt首席开发人员Daniel Berrange在2011年谈到流行的LXC容器技术:
LXC目前所依赖的DAC(自由访问控制)系统的所有安全都是不完整的，因此完全有可能意外/有意地突破容器和/或对主机OS实施DOS攻击。跟我念。”LXC还不安全。如果我想要真正的安全，我会使用KVM。”
然后。这是现在。
事情是更好。例如，大多数现代容器技术都可以使用Linux的内置安全工具，例如AppArmor对,SELinux和Seccomp政策;Grsecurity;对照组(并且);和内核命名空间。
哇!有那么多安全缩写难道你不觉得安全吗?你不应该。这是为什么。
Docker和其他容器技术以root身份运行
我直接引用了容器技术中最流行的Docker的安全文档:“使用Docker运行容器(和应用程序)意味着运行Docker守护进程。这个守护进程目前需要root权限。
是的，Docker和许多其他容器技术都需要root访问来实现它们的魔力。而且，就像其他需要root访问的程序一样，强大的功能也会带来巨大的破坏机会。
卡耐基梅隆大学CERT研究员Aaron Cois最近告诉《纽约时报》DevOps出版，“我认为Docker最大的威胁之一是它的定位和语言隐含的安全性。事实上，这些容器里什么都没有对于root访问，确实是这样。
当然，正如Docker建议的，可以将使用Docker的能力限制为“可信用户”，但即使可信用户也有使用错误密码的糟糕习惯。值得信任的用户很容易做一些不值得信任的事情。
容器本身不需要root访问。当然，服务器和虚拟机(vm)需要root用于SSH、cron、syslogd等。容器没有。这些作业可以由承载容器的操作系统处理。因此，如果您锁定了容器，仅仅在容器中获得根并不是那么糟糕。
或者,是吗?
正如NCR安全专家Lenny Zeltzer最近所写的:“从那时起Docker没有为每个容器提供自己的用户名称空间，没有用户ID隔离。”A process process running as root (UID 0) in a container has root-level privileges on the underlying host when interacting with the kernel.
再想想，永远不要在容器中以根运行任何东西。如果你这样做，你就是在自找麻烦。
Zeltzer补充道:“Docker将底层主机的许多方面与运行在没有root权限的容器中的应用程序隔离开来。但是，这种分离不如虚拟机那样强大，虚拟机在hypervisor上运行独立的OS实例，而不与底层OS共享内核。”
当然，如果黑客可以访问底层操作系统，那么就会有一个讨厌的根访问守护进程等待引起麻烦。
此外，与从容器进入守护进程相比，进入守护进程的方式更多。Docker建议，如果您通过API使用web服务提供Docker容器，那么应该特别注意参数检查。由于Docker和其他容器通常是使用具象状态传输(Representational State Transfer, REST)应用程序编程接口(api)设置的，这为黑客留下了许多潜在的易受攻击的表面。如果你选择做这件事，你就可以必须使用安全套接字层(SSL) web连接，通过虚拟专用网(VPN)进行连接也不会有什么不妥。
考虑到Docker守护进程的潜在危害，在它们自己的服务器上运行Docker实例也是一个好主意。应该在这些服务器上运行的其他软件只有SSH服务器和监视和日志程序，比如远程插件扩展器(NRPE)。
你在这个容器中使用什么软件?
如果您在您的容器中构建您使用的所有软件，那么您将是您自己的安全技能集所允许的最安全的。不幸的是，许多人已经转向从容器存储库获取容器。这里的问题是，你不能确切地知道你得到的是什么。它到底是一个MySQL容器，还是一个拥有SSH服务器的MySQL容器，在等待黑帽创建者的命令?
你不知道。这些容器需要检查。您不能简单地获取一个GitHub容器并运行它而不承担可怕的风险。使用未知的容器就像，你可以想象危险的行为和可能导致的感染。
假设您确实从一个“可信”源获得了容器。你真的能相信它吗?也许吧。也许不是。
比如DockerDocker 1.3中的数字签名自动验证所有的来源和完整性官方码头工人回购。但是不要太激动。该公司继续表示:“这项功能仍在进行中:目前，如果官方图像被损坏或篡改，Docker会发出警告，但不会阻止其运行。非官方的图片也没有得到证实。这将在未来的版本中改变，因为我们加强了代码并消除了不可避免的可用性怪癖。在那之前，请不要依赖这个功能来保证真正的安全。”Today, it's still a work in progress.
别以为我是在欺负Docker。除了Solaris区域，所有容器技术都存在这些问题。不幸的是，除非您正在运行Solaris，否则区域无法帮助您将服务器应用程序迁移到容器。
展望未来
有一个旧的项目管理说，在这些选择中，你可以有三分之二的选择:快速、良好或廉价。CoreOS的首席安全工程师马修·加勒特(Matthew Garrett)说，集装箱运输方便、便宜、安全。每个不迷恋容器魅力的人都知道这一点。
问题是“谁来做使容器更安全的工作?”
Garrett认为，虽然现代容器部署工具利用了许多内核安全特性……有一些缺乏来自销售集装箱服务的公司的贡献。这里有意义的工作包括:
- 在实际配置下对容器进行强审计和主动模糊处理
- 支持在名称空间中有意义地嵌套Linux安全模块
- 容器状态的内省和(更困难的)主机操作系统本身，以识别妥协
由于Garrett最近被CoreOS雇佣，他将处理这些问题。他接着说:
这些工作不容易，但很重要，我希望在这类领域缺乏明显的发展只是技术年轻化的一个症状，而不是缺乏让事情变得更好的有意义的愿望。但除非情况有所改善，否则人们很容易就会认为集装箱是一种“方便、便宜、安全:选择两种”的权衡。这不是一个成功的策略。
他说得对，这并不容易。而且，正如他在其他场合总是明智地指出的那样，”距离上次重大安全故障已经0天了。它将永远是。”
没错，但集装箱将变得更加安全。他们必须这样。
我很遗憾地说，在安全成为疯狂发展的容器技术的首要任务之前，它可能会经历一两次灾难，但它会的。然后，在需要做安全的教训正确下沉，集装箱将最终准备生产。
“对于容器，安全性是问题#1”这篇文章最初由ITworld 。