DockerHub上30%的镜像有漏洞吗？通过漏洞计算，发现确实存在高比例的漏洞。对于官方镜像，请遵循Docker的安全指南。如果是自己创建镜像，可以找源码仓库或者自己处理。但是我们发现这些漏洞大部分都是旧镜像。面对有漏洞的图片，我们可以采取局部措施，也可以使用web安全审查来检查。如果想让Docker更安全，推荐使用dockerbench来评估。该文章还解释了容器的用途。这个数字太惊人了！不是因为比例太高或太低，而是因为有这样一个比例。既然有可能（比较容易）计算出这个比例，就意味着有可能（比较容易）提高这个比例。免责声明：本人是一名Docker官方人士，但本人并未获得公司认可撰写本文，所以***带着批判性思维阅读本文。这个数字来自BanyanOps博客。漏洞计算首先，我们来看一下原文中的数据是如何计算的。这个过程比较简单：获取Docker注册中心列表下载列表中的镜像检查镜像中的漏洞这一步似乎太简单了，让我们稍微深入一下。列出镜像列出官方镜像很容易。这些图像是使用称为bashbrew的自动化系统使用公开可用的方法构建的。顺便说一句，这意味着如果你想重建官方镜像，这很容易做到。（请记住，这些方法涉及一些在引导时使用的blob或tarball；因此有时您需要做一些额外的工作来重建这些blob或tarba）。官方镜像的构建方法可以在Github上的docker-library仓库中找到。列出其他镜像（即非官方用户和组织拥有的镜像）更加困难。DockerHub目前不提供任何方式来枚举它们，因此一个临时的解决方法是搜索一个非常宽泛的关键字，然后提取结果。当然，这需要一些刮擦；抓取的结果可能会遗漏一些用户数据，但你会非常接近。（虽然这当然是可能的，但我还听说新的注册表界面有一些非常好的功能，可以使这更容易）。下载镜像下载镜像是一项繁琐的工作。如果您想安静地执行此操作，请运行docker守护进程并执行dockerpullusername/imagename:tag。如果你想获得容器文件系统的压缩包，很简单：只需运行dockerexportusername/imagename:tag。（记得把stdout重定向到别处，不然你的终端会崩溃）如果你不是很信任Dockerdaemon进程，你可以检查注册接口（v1，v2）并通过接口下载layer，然后Reorganizelayerfiles成镜像文件。我想留给你一些细节，但层文件只是普通的tarball，你只需将它们解压在彼此之上（需要保持正确的顺序）以重新组合成图像文件。没有特别难的步骤；唯一要注意的是“whiteout”。“空白”是一个特殊的标记文件，用来表示“这里曾经存在一个文件，但现在不存在了”。换句话说，如果一个层包含文件/etc/foo.conf，但上层将其删除，则上层将包含一个文件/etc/.wh.foo.conf，并且foo.conf不会出现在容器。这个文件相当于给空白文件加了掩码。后来才知道Tianon大神为此写了一个脚本，有兴趣的可以看看。#p#检查图像在这个阶段，您需要做一些事情。细节太多，无法在本文中描述；但在全面的安全检查中，您可能需要执行以下步骤：运行yum-security或类似命令以确保此时没有安全更新；或者更好：列出所有已安装的包及其版本，然后检查包是否包含该版本的漏洞；计算系统中每个文件的哈希值，然后与已知易受攻击文件的哈希集进行比较；执行自动化工具（例如chkrootkit）查找可疑文件；运行一定数量的针对特定漏洞量身定制的漏洞测试。这些测试的目的是尝试利用某些漏洞，然后告诉您，“您的系统存在漏洞，因为我设法利用了它”或“我无法利用此漏洞，因此您的系统可能没有此漏洞”脆弱性”。容器上下文中的事情变得有趣，因为使用Docker可以轻松方便地自动执行这些步骤。例如，您可以将您的漏洞分析工具包放在/tmp/toolkit中，然后对于每个图像$I，执行dockerrun-v/tmp/toolkit:/toolkit$I/toolkit/runall.sh。（注意：这假设您的工具包是静态链接和/或自包含的，即不依赖于容器映像中的任何内容，因为这可能再次允许您的工具包被欺骗。我的主要观点是是的，如果你想通过一系列测试来检查你的容器镜像，你可以使用容器让这一步变得非常简单，而且整个过程会快很多，因为你不需要为每个测试机器副本做一个单独的检查）boostmetrics然后在我们运行这些测试之后，我们发现包含易受攻击包的图像的比例高得惊人。我们如何改进这个指标？对于官方镜像，最简单的方法是遵循Docker的安全指南。未来随着官方镜像数量的增加，Docker也会完善这个机制，达到自动提示官方镜像上游安全列表的效果。对于非官方镜像，可以查看镜像中的Author字段：$dockerinspect--format'{{.Author}}'bin/ngrepJeromePetazzoni如果镜像是自动构建的，可以找到出处的仓库，直接联系他们。如果您直接受到错误的影响并希望事情进展得更快，您可以自己重建图像，和/或研究如何修复错误，并提交包含修复的PR。这里的意图并不是将安全的责任推给镜像的使用者，而是让那些愿意并且能够修复这些漏洞的人为Docker镜像的安全做出贡献。将来，这些步骤将得到完善和简化。将建立一个自动化流程，以减少联系相关机构的繁琐需要，然后最大限度地减少发布包含漏洞补丁的版本的时间。但是30%太多了，对吧？30%的“易受攻击的图像”可能听起来很多。这是我第一次听到时的想法。但是如果你仔细观察，你会发现大部分图像都是旧图像，这些图像是__故意不更新__的。什么？__不被故意更新__？是的，对此有一些很好的解释。首先是（部分）照顾其他媒介。一些发行版希望XYZ在CD/DVD、网络安装、VM映像和容器中保持一致。第二个原因（也解释了第一个原因）是可重复构建。假设您有一台运行12.04的服务器，但您无法使用新的Ubuntu12.04版本（更不用说14.04）来重现它了。深入挖掘后，发现问题只存在于特定时间安装的12.04.02版本的机器上。如果容器镜像的版本为12.04.02，则可以重现该错误；否则，您将不得不从其他地方获取该特定版本。这就是为什么DockerHub有很多旧镜像在发布时仍然存在——并且在发布时包含安全问题。话虽如此，我们已经放置了一条安全警告，上面写着“历史镜像-远离”，因此我们更希望在计算这些安全指标时不应包括镜像。希望下次有人计算安全指标时，他们会意识到这一点。在本地采取行动我们可能正在运行一个有问题的图像！帮助！怎么办，怎么办？事情并不像看起来那么糟糕。当您（或其他人）对这些镜像（官方的、公共的、私有的）进行审查时，结果是一个镜像列表（具有唯一的哈希字符串），并包含“通过”或“失败”状态。（对于“FAIL”图像，您可能想知道它失败的一些细节，例如：“似乎有ShellShock/CVE-2014-7187和其他漏洞”或“包含包OpenSSL1.0.1c/CVE-2014-0160".)Web-scalesecurityreview你可以把这个列表和你本地的镜像进行比较。这就是事情变得有趣的地方。根据此列表对您的本地图像进行简单且廉价的匹配，您会立即知道您是否正在运行易受攻击的图像。这可以很容易地扩展到数亿台主机。这也意味着事情可以很好地解耦：您的安全审计员不需要访问您的生产环境（甚至您的开发环境中的系统）。他们甚至不需要知道您运行的是什么图像：他们只需对图像进行大规模分析并为您提供结果。您甚至可以获得多家安全公司的结果并比较它们的结果。#p#如果我的图像在创建后被修改了怎么办？对于新手，你不应该这样做。如果你想更新容器中的某些东西，你应该创建一个新镜像并运行该新镜像。好的，但如果我已经完成了呢？好吧，没有告诉，但至少我们会知道你做到了。作为安全审计的一部分，您可以在运行的容器上运行dockerdiff以查看它们是否已被修改。（通常dockerdiff是没有结果的。注意，如果你用shell启动了一个容器，或者在容器中执行了dockerexec，你可能会看到一个小的变化。但是生产环境中的容器应该不会有任何变化的结果。）专业提示：您甚至可以通过在容器中使用--read-only标志来防止更改来实现此目的。这使得容器的文件系统成为只读的，确保dockerdiff结果为空。如果你想用一个命令检查所有容器，你可以执行：dockerps-q|xargs-I{}dockrdiff{}（感谢@diogomonica的命令！）我已经构建了自定义容器如果你构建自己的容器呢，我建议您将它们上传到存储库。如果是公众，我们就会出现我们最初讨论的情况。如果这是私人的，让我们看下一节！私有镜像和注册表呢？如果您上传私人图片怎么办？如果你上传到本地注册表，或者DockerHub企业版呢？事情显然变得越来越复杂。你可能会看到有人告诉你“假设ABC容易受到CVE-XYZ的攻击”，如果他们从未见过镜像ABC。以下是一些可能发生的事情：安全提供商可以提供一个图像扫描仪，您可以在自己的图像上使用它；安全提供商可以更进一步，将其集成到Docker的注册表中。这可以通过分配读取权限（访问DockerHub上的私有图像）或部署本地安全扫描器（对于DockerHub企业版）来完成。在这两种情况下，图像一上传就会自动扫描，并立即报告它可能包含的任何漏洞。结束语有两点我想强调一下，因为我相信这可以在安全领域产生很好的效果。想出数字是件好事。一旦我们量化了数据，我们就可以改进它们。Docker非常重视安全性，您可以肯定我们将与社区和镜像维护者合作来改进这些量化数字。围绕Docker和DockerHub有一个像这样的生态系统和社区，使它们成为制定标准的地方。正如Soloman在一些主题演讲中指出的那样，Docker最重要的一点不是技术，而是人们对某件事达成共识。后一点意味着Docker现在有足够多的批评者来纠正横向工具（包括安全审查）以使生态系统受益。结果将是更好的安全机制，使每个人都受益。Docker注重安全如果你有这样的印象，Docker公司不注重安全，那么真相离你太远了。如上所述，我们有负责任的披露安全政策，而且我们总是能迅速解决我们意识到的问题。没有软件是没有错误的。Docker也是人写的，虽然有些写的很好，但还是会出错。重要的是我们对安全报告的重视程度，我们处理它们的速度有多快；如果你想让你的Docker环境更安全，我建议你看看dockerbench。我与人合着了它，其中包括一个自动评估工具，可用于使用CISDocker1.6Benchmark评估Docker主机。它会检查很多事情（例如SELinux和AppArmor是否启用）并生成报告。这是Docker将要推出或参与的第一批软件，目的是让你不用博士也能安全掌握Docker。Docker容器安全证书，或者不雇用TaylorSwift。正确运行Docker。而且，我们鼓励公开讨论，包括安全问题。Docker库存储库对此主题进行了非常有趣的讨论。额外提示我被要求解释如果我们不仔细检查我们运行的所有内容的来源，为什么容器是有用的。下面是一些例子：容器允许我们在沙盒环境中测试一些危险的操作（比如著名的curl...|sh），并且可以看到什么可以产生结果，这得益于dockerdiff。容器让我们可以在沙箱环境下测试一些危险的操作（比如商业软件的install.sh），我们可以看到能产生什么结果，这要感谢dockerdiff。容器让我们可以在沙箱环境下测试一些危险的操作（比如安装一个npm、pip、gem等的包，但我们不知道它的来源），我们可以检查它是否能产生结果，这样的好处来自dockerdiff。容器让我们可以在沙箱环境中测试一些危险的操作（比如安装一个deb、rpm或其他分发包），并且可以看到什么可以产生结果，这得益于dockerdiff。容器允许我们在沙箱环境中测试一些危险的操作（比如安装一个危险的squid包），我们可以看到可以产生什么结果，这得益于dockerdiff。我想你可以看到模式。仅仅因为事物以熟悉的形式呈现给您并不意味着它们是安全的。但是我们可以使用Docker来提高安全性。原文链接：http://www.linuxidc.com/Linux/2015-06/118869.htm
