Docker容器构建环境及安全措施分析.doc

《Docker容器构建环境及安全措施分析.doc》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、Docker容器构建环境及安全措施分析　　DevOps概念的流行跟近些年微服务架构的兴起有很大关系，DevOps是Dev（Development）和Ops（Operations）的结合，Dev负责开发，Ops负责部署上线，Docker出现之前，公司需要搭建一个数据库环境，有了Docker之后，只需在一些开源的基础镜像上构建出公司自己的镜像即可。　　因此目前大多数DevOps设置都在CI管道中的某处设置了Docker，这就意味着你所看到的任何构建环境都将使用Docker等容器解决方案。由于这些构建环境需要接受不可信的用户提供的代码并进行执行，因此探讨如何将这

2、些代码安全地装入容器就显得非常有意义。　　在这篇文章中，我将探讨在构建环境中非常小的错误配置是如何产生严重的安全风险的。　　需要注意的是，我并未在本文描述Heroku，Docker，AWSCodeBuild或容器中的任何固有漏洞，而是讨论了在查看基于Docker容器的多租户构建环境时发现的错误配置漏洞。在常规运行下，虽然Docker容器技术提供了非常稳定的安全默认设置，但是在特殊情况时，有时候小的错误配置就会导致严重安全风险。　　特殊的构建环境　　可能的特殊构建环境可以具有以下架构：　　1.具有完全托管的生成服务，可编译源代码、运行测试以及生成可供部署的软

3、件包——AWSCodeBuild；　　2.Docker构建服务中的Docker容器；　　Docker容器可以通过Dind（Docker-in-Docker，是让你可以在Docker容器里面运行Docker的一种方式）创建，因此，从理论上来说，你最终得到两个攻击者需要逃脱的容器。使用CodeBuild可进一步最小化攻击面，因为你拥有AWS提供的一次性容器，而且租户不会与对方的构建过程互动。　　攻击者是如何控制构建过程的？　　在大多数构建或CI管道中要做的第一件事就是创建一个包含你想要构建和部署的代码的Git仓库。然后这些代码将被打包并转移到构建环境，最后应用

4、到docker构建过程。　　通过查看构建服务，你通常可以通过两种方式配置容器，即通过Dockerfile或config.yml，这两种方法都与源代码有关。　　其中有一个CI配置文件，我称之为config-ci.yml，如下图所示。　　　　在其它的构建过程开始之前，该文件将在构建过程中被转换为Dockerfile。如果你有明确指定要使用的Dockerfile环境，可以将config-ci.yml更改为以下内容。　　　　Dockerfile_Web和Dockerfile_Worker是源代码存储库中Dockerfiles的相对路径和名称，既然现在我已经提供了完

5、整的构建信息，就可以开始构建了。构建通常是通过原始仓库上的代码上传来启动的。启动时，你会看到如下所示的输出内容。　　　　正如你所看到的，输出的内容有dockerbuild-fDockerfile。这些内容即对调试过程有用，又对于发现可能出现的攻击有用。　　对预构建过程进行攻击　　在进入docker构建之前，我首先想到的是尝试并中断构建过程，或者，我可以尝试将来自CodeBuild环境的文件链接到我的Docker构建的上下文中。　　由于我已经控制了config-ci.yml文件的内容，更具体地说，我控制的是“要使用的Dockerfile的相对路径”，所以我可

6、以尝试用一种老式攻击方法——目录遍历攻击。　　第一个尝试就是试着改变构建的目录：　　　　一旦构建过程开始，我就会立即得到错误信息。　　有趣的是，该错误是我造成的，并导致了路径泄漏，如果我尝试“读取”文件会发生什么？　　　　可以看出，我解析了Docker守护进程的错误。不幸的是，这只针对我系统上的第一行文件。尽管如此，这也是一个有趣的开始。　　　　其实，我这么做的另一个想法是想尝试使用符号链接将文件包含到我的构建中。不过，Docker阻止了我这么做，因为它不会将构建目录之外的文件包含到构建上下文中。　　攻击构建过程，以发现漏洞　　让我们先回到实际的构建过程，

7、看看可以对什么进行攻击？由于构建过程发生在dindDocker容器中，该容器在一次性CodeBuild实例中运行。为了进一步寻找攻击，docker构建过程会在一次性Docker容器中运行所有命令。Docker的容器是把应用程序和环境打包在一起的，所以是一次构建，多处发布。举个例子，以前你开发完程序后，测试人员和运维人员都需要去部署，通过docker只需要一个run命令即可。因此docker最大的好处就是标准化了应用交互，同时支持多个不同平台和多个不同的云服务商，只要机器能装docker，就能无差别的运行程序。　　所以Docker构建的每一步实际上都是一个新

8、的Docker容器，这从构建过程的输出中就可以看出。　　　　在上述