🖌️
Functfan的格物致知
  • 写在前面
  • java技术
    • J2EE 全面简介
  • java安全
    • 反序列化漏洞
      • 序列化/反~
      • Ysoserial
        • Java反序列化之Vaadin1
        • Java反序列化之Groovy1
        • Java反序列化之Jdk7u21
        • Java反序列化之Commons beanUtils
        • Java反序列化之Commons-Collections
          • CommonsCollections1
          • CommonsCollections2
          • CommonsCollections1
          • CommonsCollections2
          • CommonsCollections3
          • CommonsCollections4
          • CommonsCollections5
          • CommonsCollections6
          • CommonsCollections7
      • Marshalsec
    • XXE漏洞
      • XXE爱之初印象
      • XXE漏洞写法及防御
      • XXExploiter工具
  • web安全
    • 一句话木马
  • 渗透测试
    • 网络资产收集
    • 端口服务探测
    • 边界突破
    • 内网穿透
    • 容器与K8S安全测试
  • 漏洞挖掘
    • web类框架研究报告
      • Xstream经验
      • weblogic漏洞研究经验笔记
      • WebLogic安全研究报告
    • 漏洞挖掘入门
      • 小白入门
      • 源代码审计方法
        • Java类编译与反编译基础
        • IDEA使用技巧
        • IDEA Java程序调试
      • Fuzzing技术
        • 方法论
          • fuzzing的四个技能
        • 工具集
          • tmnt-Web应用漏洞fuzzer
          • wfuzz-web app fuzzer
          • AFL-基于变异的fuzz工具
      • 物联网漏洞挖掘技术
        • 物联网设备固件模拟分析环境*(亲测下载好慢,不建议使用该教程)
        • 智能设备漏洞挖掘之固件提取
        • pwndbg调试工具使用教程
    • 漏洞情报监测
    • 漏洞安全检测工具
      • 容器安全检测脚本总结
      • WebLogic漏洞检测小工具
    • 漏洞复现
      • 操作系统
        • windows
        • Linux
          • 脏牛漏洞-Docker逃逸POC(dirtycow-vdso)代码分析
          • Dirty CoW脏牛内核提权漏洞(CVE-2016-5195)
      • 数据库
      • WEB服务组件
        • CVE-2020-2883
        • F5 BIG-IP远程代码执行漏洞(CVE-2020-5902)
        • Apache Solr 远程命令执行漏洞(CVE-2019-0193)
      • 云计算安全
        • CVE-2020-15257-容器逃逸-containerd
      • 物联网安全
        • TP-Link SR20 本地网络远程代码执行漏洞
  • CTF比赛
    • BUUCTF-练习场web
    • xctf-攻防世界新手练习区web
    • Exploit利器——Pwntools
  • 新技术研究
    • 区块链
    • 云原生安全
      • 虚拟化hypervisor简介
      • Docker容器基础
        • 云原生攻防研究:容器基础
          • Linux内核基础
          • Docker容器基础
          • 理解容器进程
          • 组件组成:剖析 Docker 组件作用及其底层工作原理
          • Docker镜像的内部结构(四)
          • docker之namespace,cgroup与unionFS
          • Linux内核安全模块之AppArmor
          • Linux沙箱之seccomp
          • Linux权限管理之Capabilities
        • 云原生攻防研究:Docker安全性与攻击面分析
        • 云原生攻防研究:容器逃逸技术概览
        • 云原生攻防研究:针对容器的渗透测试方法
        • 云原生攻防研究:漏洞缓解技术
      • Kubernetes容器编排基础
        • k8s基本概念
        • 云原生攻防研究:Kubernetes安全分析
        • 云原生攻防研究:Kubernetes攻击矩阵
    • 联邦安全
    • 云边协同
    • 安全多方计算
由 GitBook 提供支持
在本页
  • 一、base镜像
  • 1、rootfs
  • 2、base 镜像提供的是最小安装的 Linux 发行版。
  • 3、支持运行多种 Linux OS
  • 二、镜像的分层结构
  • 可写的容器层
  1. 新技术研究
  2. 云原生安全
  3. Docker容器基础
  4. 云原生攻防研究:容器基础

Docker镜像的内部结构(四)

熟悉Docker镜像内部结构

一、base镜像

base 镜像简单来说就是不依赖其他任何镜像,完全从0开始建起,其他镜像都是建立在他的之上,可以比喻为大楼的地基,docker镜像的鼻祖。

base 镜像有两层含义:(1)不依赖其他镜像,从 scratch 构建;(2)其他镜像可以之为基础进行扩展。

所以,能称作 base 镜像的通常都是各种 Linux 发行版的 Docker 镜像,比如 Ubuntu, Debian, CentOS 等。

我们以 CentOS 为例查看 base 镜像包含哪些内容。

下载及查看镜像:

root@ubuntu:~# docker pull centos
Using default tag: latest
latest: Pulling from library/centos
d9aaf4d82f24: Pull complete 
Digest: sha256:4565fe2dd7f4770e825d4bd9c761a81b26e49cc9e3c9631c58cfc3188be9505a
Status: Downloaded newer image for centos:latest
root@ubuntu:~# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
centos              latest              d123f4e55e12        3 weeks ago         197MB
ubuntu              12.04               5b117edd0b76        7 months ago        104MB

我们看到CentOS的镜像大小不到200MB,平时我们安装一个CentOS至少是几个GB,怎么可能才 200MB !

下面我们来解释这个问题,Linux 操作系统由内核空间和用户空间组成。

典型的Linux启动到运行需要两个FS,bootfs + rootfs,如下图:

1、rootfs

内核空间是 kernel,Linux 刚启动时会加载 bootfs 文件系统,之后 bootfs 会被卸载掉。用户空间的文件系统是 rootfs,包含我们熟悉的 /dev, /proc, /bin 等目录。

对于 base 镜像来说,底层直接用 Host 的 kernel,自己只需要提供 rootfs 就行了。

而对于一个精简的 OS,rootfs 可以很小,只需要包括最基本的命令、工具和程序库就可以了。相比其他 Linux 发行版,CentOS 的 rootfs 已经算臃肿的了,alpine 还不到 10MB。

我们平时安装的 CentOS 除了 rootfs 还会选装很多软件、服务、图形桌面等,需要好几个 GB 就不足为奇了。

2、base 镜像提供的是最小安装的 Linux 发行版。

下面是 CentOS 镜像的 Dockerfile 的内容:

FROM scratch
ADD centos-7-docker.tar.xz /

LABEL name="CentOS Base Image" \
    vendor="CentOS" \
    license="GPLv2" \
    build-date="20170911"

CMD ["/bin/bash"]

第二行 ADD 指令添加到镜像的 tar 包就是 CentOS 7 的 rootfs。在制作镜像时,这个 tar 包会自动解压到 / 目录下,生成 /dev, /porc, /bin 等目录。

3、支持运行多种 Linux OS

bootfs (boot file system) 主要包含 bootloader 和 kernel, bootloader主要是引导加载kernel, 当boot成功后 kernel 被加载到内存中后 bootfs就被umount了.

rootfs (root file system) 包含的就是典型 Linux 系统中的 /dev, /proc, /bin, /etc 等标准目录和文件。

由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别, 因此不同的发行版可以公用bootfs。

比如 Ubuntu 14.04 使用 upstart 管理服务,apt 管理软件包;而 CentOS 7 使用 systemd 和 yum。这些都是用户空间上的区别,Linux kernel 差别不大。

所以 Docker 可以同时支持多种 Linux镜像,模拟出多种操作系统环境。

上图 Debian 和 BusyBox(一种嵌入式 Linux)上层提供各自的 rootfs,底层共用 Docker Host 的 kernel。

这里需要说明的是:

base 镜像只是在用户空间与发行版一致,kernel 版本与发型版是不同的。

CentOS 7 使用 3.x.x 的 kernel,如果 Docker Host 是 Ubuntu 16.04,那么在 CentOS 容器中使用的实际是是 Host 4.x.x 的 kernel。

root@ubuntu:~# uname -r
4.4.0-62-generic
root@ubuntu:~# docker run -ti centos /bin/bash
[root@06f13ef13853 /]# uname -r
4.4.0-62-generic

容器只能使用 Host 的 kernel,并且不能修改。

所有容器都共用 host 的 kernel,在容器中没办法对 kernel 升级。如果容器对 kernel 版本有要求(比如应用只能在某个 kernel 版本下运行),则不建议用容器,这种场景虚拟机可能更合适。

二、镜像的分层结构

Docker 支持通过扩展现有镜像,创建新的镜像。

实际上,Docker Hub 中 99% 的镜像都是通过在 base 镜像中安装和配置需要的软件构建出来的。比如我们现在构建一个新的镜像,Dockerfile 如下:

# Version: 0.0.1
FROM debian                1.新镜像不再是从 scratch 开始,而是直接在 Debian base 镜像上构建。
MAINTAINER wzlinux
RUN apt-get update && apt-get install -y emacs        2.安装 emacs 编辑器。
RUN apt-get install -y apache2             3.安装 apache2。
CMD ["/bin/bash"]              4.容器启动时运行 bash。

构建过程如下图所示:

可以看到,新镜像是从 base 镜像一层一层叠加生成的。每安装一个软件,就在现有镜像的基础上增加一层。

问什么 Docker 镜像要采用这种分层结构呢?

最大的一个好处就是 - 共享资源。

比如:有多个镜像都从相同的 base 镜像构建而来,那么 Docker Host 只需在磁盘上保存一份 base 镜像;同时内存中也只需加载一份 base 镜像,就可以为所有容器服务了。而且镜像的每一层都可以被共享,我们将在后面更深入地讨论这个特性。

这时可能就有人会问了:如果多个容器共享一份基础镜像,当某个容器修改了基础镜像的内容,比如 /etc 下的文件,这时其他容器的 /etc 是否也会被修改?

答案是不会! 修改会被限制在单个容器内。 这就是我们接下来要说的容器 Copy-on-Write 特性。

  1. 新数据会直接存放在最上面的容器层。

  2. 修改现有数据会先从镜像层将数据复制到容器层,修改后的数据直接保存在容器层中,镜像层保持不变。

  3. 如果多个层中有命名相同的文件,用户只能看到最上面那层中的文件。

可写的容器层

当容器启动时,一个新的可写层被加载到镜像的顶部。这一层通常被称作“容器层”,“容器层”之下的都叫“镜像层”。

典型的Linux在启动后,首先将 rootfs 置为 readonly, 进行一系列检查, 然后将其切换为 “readwrite” 供用户使用。在docker中,起初也是将 rootfs 以readonly方式加载并检查,然而接下来利用 union mount 的将一个 readwrite 文件系统挂载在 readonly 的rootfs之上,并且允许再次将下层的 file system设定为readonly 并且向上叠加, 这样一组readonly和一个writeable的结构构成一个container的运行目录, 每一个被称作一个Layer。如下图所示。

所有对容器的改动,无论添加、删除、还是修改文件都只会发生在容器层中。只有容器层是可写的,容器层下面的所有镜像层都是只读的。

下面我们深入讨论容器层的细节。

镜像层数量可能会很多,所有镜像层会联合在一起组成一个统一的文件系统。如果不同层中有一个相同路径的文件,比如 /a,上层的 /a 会覆盖下层的 /a,也就是说用户只能访问到上层中的文件 /a。在容器层中,用户看到的是一个叠加之后的文件系统。

  1. 添加文件:在容器中创建文件时,新文件被添加到容器层中。

  2. 读取文件:在容器中读取某个文件时,Docker 会从上往下依次在各镜像层中查找此文件。一旦找到,立即将其复制到容器层,然后打开并读入内存。

  3. 修改文件:在容器中修改已存在的文件时,Docker 会从上往下依次在各镜像层中查找此文件。一旦找到,立即将其复制到容器层,然后修改之。

  4. 删除文件:在容器中删除文件时,Docker 也是从上往下依次在镜像层中查找此文件。找到后,会在容器层中记录下此删除操作。

只有当需要修改时才复制一份数据,这种特性被称作 Copy-on-Write。可见,容器层保存的是镜像变化的部分,不会对镜像本身进行任何修改。

这样就解释了我们前面提出的问题:容器层记录对镜像的修改,所有镜像层都是只读的,不会被容器修改,所以镜像可以被多个容器共享。

上一页组件组成:剖析 Docker 组件作用及其底层工作原理下一页docker之namespace,cgroup与unionFS

最后更新于4年前

参考文档:<; <;

http://developer.51cto.com/art/201312/424374_all.htm>
https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/>