Docker 安全实践

Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。 镜像不包含任何动态数据，其内容在构建之后也不会被改变。

分层存储 :sparkles:

因为镜像包含操作系统完整的 root 文件系统，其体积往往是庞大的，因此在 Docker 设计时，就充分利用 [Union FS]的技术，将其设计为分层存储的架构。所以严格来说，镜像并非是像一个 ISO 那样的打包文件，镜像只是一个虚拟的概念，其实际体现并非由一个文件组成，而是由一组文件系统组成，或者说，由多层文件系统联合组成。

尝试下docker  pull ubuntu：

镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。比如，删除前一层文件的操作，实际不是真的删除前一层的文件，而是仅在当前层标记为该文件已删除。在最终容器运行的时候，虽然不会看到这个文件，但是实际上该文件会一直跟随镜像。因此，在构建镜像的时候，需要额外小心，每一层尽量只包含该层需要添加的东西，任何额外的东西应该在该层构建结束前清理掉。

例如如上Dockerfile 中每一个指令都会建立一层，RUN 也不例外。每一个 RUN 的行为，就和刚才我们手工建立镜像的过程一样：新建立一层，在其上执行这些命令，执行结束后， commit 这一层的修改，构成新的镜像。而上面的这种写法，创建了 7 层镜像。

总结：镜像就是打包的、分层的文件系统。

2.2  容器

镜像（ Image ）和容器（ Container ）的关系，就像是面向对象程序设计中的 类 和 实例 一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。

容器的实质是进程，但与直接在宿主执行的进程不同，容器进程运行于属于自己的独立的 [命名空间]因此容器可以拥有自己的 root 文件系统、自己的网络配置、自己的进程空间，甚至自己的用户 ID  空间。容器内的进程是运行在一个隔离的环境里，使用起来，就好像是在一个独立于宿主的系统下操作一样。这种特性使得容器封装的应用比直接在宿主运行更加安全。

总结：容器就是供镜像运行的进程，具有独立的命名空间（namespaces）。

2.3  仓库

镜像构建完成后，可以很容易的在当前宿主机上运行，但是，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务， Docker Registry 就是这样的服务。

一个  Docker Registry 中可以包含多个  仓库 （ Repository ）；每个仓库可以包含多个  标签 （ Tag ）；每个标签对应一个镜像。

通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。我们可以通过 <仓库名>:<标签> 的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以 latest 作为默认标签。

以 [Ubuntu 镜像]为例， ubuntu  是仓库的名字，其内包含有不同的版本标签，如， 16.04 ,   18.04 。我们可以通过   ubuntu:16.04 ，或者   ubuntu:18.04   来具体指定所需哪个版本的镜像。如果忽略了标签，比如  ubuntu ，那将视为  ubuntu:latest 。

仓库名经常以 两段式路径 形式出现，比如   jwilder/nginx-proxy ，前者往往意味着 Docker Registry 多用户环境下的用户名，后者则往往是对应的软件名。但这并非绝对，取决于所使用的具体 Docker Registry 的软件或服务。

Docker Registry公开服务：例如Docker Hub\Quay.io\Google Container Registry。

私有 Docker Registry：比如Harbor和 Sonatype Nexus。

2.4  Docker架构

Docker的文件系统是分层的，它的rootfs在mount之后会转为只读模式。Docker在它上面添加一个新的文件系统，来达成它的只读。

事实上，从下图中，我们能看到多个只读的文件系统，Docker中把他们称为 层（layer）。

image是只读的，container部分则是可写的。

如果用户想要修改底层只读层上的文件，这个文件就会被先拷贝到上层，修改后驻留在上层，并屏蔽原有的下层文件。

最后一部分是容器(container)， 容器是可读写的。

在系统启动时，Docker会首先一层一层的加载image，直到最先面的base image。而这些image都是只读的。

最后，在最上层添加可读写的一个容器， 这里存放着诸如unique id，网络配置之类的信息。

既然是可读写的，就会有状态。容器共有两种状态：running 和 exited.

用户也可以用Docker commit 命令（不推荐使用）将一个容器压制为image，供后续使用。

3、Docker生态

Kubernetes

建于 Docker 之上的 Kubernetes 可以构建一个容器的调度服务，其目的是让用户透过 Kubernetes 集群来进行云端容器集群的管理，而无需用户进行复杂的设置工作。系统会自动选取合适的工作节点来执行具体的容器集群调度处理工作。其核心概念是 Container Pod 。一个 Pod 由一组工作于同一物理工作节点的容器构成。这些组容器拥有相同的网络命名空间、IP以及存储配额，也可以根据实际情况对每一个 Pod进行端口映射。此外， Kubernetes 工作节点会由主系统进行管理，节点包含了能够运行 Docker 容器所用到的服务。

kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它可以通过以下方式向 apiserver 进行注册：主机名（hostname）； 覆盖主机名的参数；某云服务商的特定逻辑。

• 节点（ Node ）： 一个节点是一个运行 Kubernetes 中的主机。

• 容器组（ Pod ）： 一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷(volume)。

• 容器组生命周期（ pos-states ） ：包含所有容器状态集合，包括容器组状态类型，容器组生命周期，事件，重启策略，以及 replication controllers。

• Replication Controllers： 主要负责指定数量的 pod 在同一时间一起运行。并且在任何时候都有指定数量的Pod副本，在此基础上提供一些高级特性，比如滚动升级和弹性伸缩

• 服务（ services ）： 一个 Kubernetes 服务是容器组逻辑的高级抽象，同时也对外提供访问容器组的策略。

• 卷（ volumes ）： 一个卷就是一个目录，容器对其有访问权限。

• 标签（ labels ）： 标签是用来连接一组对象的，比如容器组。标签可以被用来组织和选择子对象。

• 接口权限（ accessing_the_api ）： 端口，IP 地址和代理的防火墙规则。

• web 界面（ ux ）： 用户可以通过 web 界面操作 Kubernetes。

• 命令行操作（ cli ）： kubectl命令。

4、Docker文件 存储驱动

Docker的overlay存储驱动利用OverlayFS（堆叠文件系统）的一些特征来构建以及管理镜像和容器的磁盘结构。

docker1.12后推出的overlay2在inode的利用方面比ovelay更有效， overlay2要求内核版本大于等于4.0。

4.1   overlay

(由较早的kernel以及Docker版本使用)

如下图所示，overlay在主机上用到2个目录，这2个目录被看成是overlay的层。upperdir为容器层、lowerdir为镜像层使用联合挂载技术将它们挂载在同一目录(merged)下，提供统一视图。

当容器层和镜像层拥有相同的文件时，容器层的文件可见，隐藏了镜像层相同的文件。然后由容器挂载目录(merged)提供了统一视图。

overlay只使用2层，意味着多层镜像不会被实现为多个OverlayFS层。每个镜像被实现为自己的目录，这个目录在路径/var/lib/docker/overlay下。 硬链接 被用来索引和共享底层的数据，节省了空间。

当创建一个容器时，overlay驱动连接代表镜像层顶层的目录(只读)和一个代表容器层的新目录(读写)：

一开始overlay路径下为空，用docker pull命令下载一个由5层镜像层组成的docker镜像:

此时，在路径/var/lib/docker/overlay/下，每个镜像层都有一个对应的目录，包含了该层镜像的内容，通过tree命令发现，每个镜像层下只包含一个root目录 (因为docker1.10开始，使用基于内容的寻址，因此目录名和镜像层的id不一致)。

每一层都包含了”该层独有的文件”以及”和其低层共享的数据的硬连接”。如ls命令，每一层都使用一个硬链接来指向实际ls命令的inode号(405241)：

使用刚刚拉取的ubuntu镜像创建一个容器（docker run --name test -d -it ubuntu:latest /bin/bash），用docker ps命令查看：

创建容器时，实际上是在已有的镜像层上创建了一层容器层，容器层在路径/var/lib/docker/overlay下也存在对应的目录：

“6abc47……”和“6abc47…..-init”为创建容器后 新增的目录。 查看这两个目录的内容：

“6abc47……”为读写层，“6abc47…..-init”为初始层。初始层中大多是初始化容器环境时，与容器相关的环境信息，如容器主机名，主机host信息以及域名服务文件等。所有对容器做出的改变都记录在读写层。

文件lower-id用来索引该容器使用的镜像层，upper目录包含了容器层的内容，每当启动一个容器时，会将lower-id指向的镜像层目录以及upper目录联合挂载到merged目录，因此，容器内的视角就是merged目录下的内容。而work目录则是用来完成如copy-on_write的操作。

看看容器层使用到了哪一层镜像层：

在刚才创建的容器中创建一个文件：

4.2  overlay2

和overlay为了实现“两个目录反映多层镜像“而使用硬链接不同，overlay2驱动天生支持多层。(最多128层)

因此，overlay2在使用docker层相关的命令时，能提供更好的性能(如：docker build、docker commit)。而且overlay2消耗的inode节点更少。

docker pull ubuntu拉取完一个5层的Ubuntu镜像后，/var/lib/docker/overlay2下可以看到几个目录:

"I"目录包含一些符号链接作为缩短的层标识符. 这些缩短的标识符用来避免挂载时超出页面大小的限制，每个标示符对应不同层级的diff目录。

最底层包含”link”文件(不包含lower文件，因为是最底层)，在上面的结果中“c7fae….”为最底层。这个文件记录着作为标识符的更短的符号链接的名字、最底层还有一个”diff”目录(包含实际内容)。

从第二层开始，每层镜像层包含”lower“文件，根据这个文件可以索引构建出整个镜像的层次结构。”diff“文件(层的内容)。还包含”merged“和”work”目录，用途和overlay一样。

再来看看容器层，容器层的文件构成和镜像层类似(这点和overlay不同)，使用刚刚拉取的ubuntu镜像创建一个容器(docker run --name test -d ubuntu:latest)，/var/lib/docker/overlay2目录下新增2个目录：

查看容器层通过lower目录索引的镜像层明细：

对于读，考虑下列3种场景：

• 读的文件不在容器层： 如果读的文件不在容器层，则从镜像层进行读

• 读的文件只存在在容器层： 直接从容器层读

• 读的文件在容器层和镜像层： 读容器层中的文件，因为容器层隐藏了镜像层同名的文件

对于写，考虑下列场景：

• 写的文件不在容器层，在镜像层： 由于文件不在容器层，因此overlay/overlay2存储驱动使用copy_up操作从镜像层拷贝文件到容器层，然后将写入的内容写入到文件新的拷贝中

• 删除文件和目录： 删除镜像层的文件，会在容器层创建一个whiteout文件来隐藏它；删除镜像层的目录，会创建opaque目录，它和whiteout文件有相同的效果

• 重命名目录： 对一个目录调用rename仅仅在资源和目的地路径都在顶层时才被允许，否则返回EXDEV（场景较少，未做深入研究）

5、Docker镜像与层级的概念

5.1  Docker镜像与层级详解

因为镜像包含操作系统完整的  root  文件系统，其体积往往是庞大的，因此在 Docker 设计时，就充分利用 [Union FS]的技术，将其设计为分层存储的架构。所以严格来说，镜像并非是像一个 ISO 那样的打包文件，镜像只是一个虚拟的概念，其实际体现并非由一个文件组成，而是由一组文件系统组成，或者说，由多层文件系统联合组成。

最终最高层的镜像层成为只读的init layer层，其与读写权限的容器层以及mount的宿主机文件路径，共同成为容器的文件系统。

尝试下docker  pull ubuntu：

可以发现一个ubuntu镜像存在多个sha256的digestid，用来标示不同层级的layerid(涂层)，我们可以通过docker inspect ubuntu查看每个镜像层级的digest sha256的值：

[[email protected] lijianxin1]# docker inspect ubuntu

除了基础镜像存储驱动层，还有容器挂载的目录（Volumes）以及dockerfile中指定的WorkDir(工作目录)：

5.2  Docker镜像扫描的实现

之前讲到Docker的存储驱动overlay2，Docker会在/var/lib/docker/image目录下给使用的存储驱动创建一个目录：/var/lib/docker/overlay2。

这里的关键地方是 imagedb 和 layerdb 目录，看这个目录名字，很明显就是专门用来存储元数据的地方，那为什么区分image和layer呢？因为在docker中，image是由多个layer组合而成的，换句话就是layer是一个共享的层，可能有多个image会指向某个layer。

通过docker image ls找到镜像id，我的是1e4467b07108

我们打印 /var/lib/docker/image/overlay2/imagedb/content/sha256 这个目录：

第一行的 1e4467b07108685c38297025797890f0492c4ec509212e2e4b4822d367fe6bc8 正是记录我们 ubuntu 镜像元数据的文件，接下来cat一下这个文件，得到一个长长的json：

由于篇幅原因，我只展示最关键的一部分，也就是 rootfs 。可以看到rootfs的diff_ids是一个包含了3个元素的数组，其实这3个元素正是组成 nginx 镜像的3个layerID，从上往下看，就是底层到顶层，也就是说

ce30112909569cead47eac188789d0cf95924b166405aa4b71fb500d6e4ae08d 是i mage的最底层。既然得到了组成这个image的所有layerID，那么我们就可以带着这些layerID去寻找overlay中对应的文件目录了。

我们返回到上一层的 layerdb 中，先打印一下这个目录：

在这里我们只管 mounts 和 sha256 两个目录，再打印一下 sha256 目录:

/var/lib/docker/image/overlay2/layerdb 存的只是元数据，那么真实的rootfs到底存在哪里呢？其中cache-id就是我们关键所在了。我们打印一下 /var/lib/docker/image/overlay2/layerdb/sha256/ce30112909569cead47eac188789d0cf95924b166405aa4b71fb500d6e4ae08d/cache-id :

没错，这个id就是对应 /var/lib/docker/overlay2/c7fae7e34df9196dacbb4a23f858758d14737d9a0e4168056126c7c540d8f6c8

通过以上技术手段，那我们能够获取一个镜像(image)所有layerid对应的overlay2存储驱动的层级，这个层级中diff目录包含了实际容器层使用的文件系统。

那么通过递归探测镜像所有layer层完整的系统文件路径，可以获得：

1、镜像系统版本，安装的软件包版本记录等

2、探测镜像已安装的软件包

上一步已经探测到了操作系统，自然可以知道系统的软件管理包是rpm还是dpkg。

centos系统的软件管理包是rpm，而debain系统的软件管理是dpkg。下面是不同软件管理包的目录：

比如debian系统，从文件/var/lib/dpkg/status文件则可以探测到当前系统安装了哪些版本的软件。

现在horbor已经集成Clair镜像安全扫描组件： https://blog.csdn.net/arnolan/article/details/102666831?utm_medium=distribute.pc_relevant.none-task-blog-baidujs-1

6、Docker namespaces与cgroup概念