RedHat OpenShift QuickStart 2.3 容器注册

Posted 2020-11-27 tiandz

原文：https://learn.openshift.com/subsystems/container-internals-lab-2-0-part-3

一、了解信任的基础——质量和来源

深入的了解注册服务器和存储库，这需要知晓质量和出处，简单的来说就是：

1. 必须下载信任的事物
2. 你必须从信任的仓库去下载

单独哪一个都是不够的，二者缺一不可。自从为Linux发行版下载ISO映像以来，这一直是事实。无论是评估开源库还是代码、预构建包(RPMs或Debs)还是容器镜像，我们都必须:

1. 通过评估项目中涉及的代码，人员和组织的质量来确定我们是否信任该镜像。 如果它有足够的历史，投资并能真正为我们服务，我们就会开始信任它。
2. 通过了解注册中心与受信任项目之间关系的质量来确定我们是否信任注册中心——如果我们从官方的GitHub repo下载了一些东西，那么我们就比从某个的fork上下载更信任它。对于来自镜像站点的ISOs和由与底层代码或包无关的人构建的镜像库来说，情况确实如此。

有很多这样的例子，人们忽略了上面的一个而被黑。在以前的分享中，我们学习了如何将URL分解为注册服务器、名称空间和存储库。

 

可信任的事物：

从安全的角度来看，在下载、展开和将镜像缓存到容器引擎的本地存储之前，最好远程检查并确定是否信任镜像。每次下载镜像并将其暴露给容器引擎中的图形驱动程序时，我们都将自己暴露在潜在的攻击之下。首先，让我们用Skopeo做一个远程检查(由于客户端/服务器的性质，Docker无法做到这一点):

skopeo inspect docker://registry.fedoraproject.org/fedora

$ skopeo inspect docker://registry.fedoraproject.org/fedora
{
    "Name": "registry.fedoraproject.org/fedora",
    "Digest": "sha256:d5cb1a0e55912dc9057e624d5843db0074f3be21bbd67a45e904abb45a89f43d",
    "RepoTags": [
        "24",
        "25",
        "26-modular",
        "26",
        "27-aarch64",
        "27-armhfp",
        "27-ppc64le",
        "27-x86_64",
        "27",
        "28-aarch64",
        "28-armhfp",
        "28-ppc64le",
        "28-x86_64",
        "28",
        "29-aarch64",
        "29-ppc64le",
        "29-s390x",
        "29-x86_64",
        "29",
        "30-aarch64",
        "30-ppc64le",
        "30-s390x",
        "30-x86_64",
        "30",
        "latest",
        "rawhide",
        "30-armhfp",
        "29-armhfp",
        "31-aarch64",
        "31-x86_64",
        "31",
        "31-armhfp",
        "31-s390x",
        "31-ppc64le",
        "32-aarch64",
        "32-ppc64le",
        "32-s390x",
        "32-x86_64",
        "32",
        "33-aarch64",
        "33-ppc64le",
        "33-s390x",
        "33-x86_64",
        "33"
    ],
    "Created": "2020-02-24T05:48:23Z",
    "DockerVersion": "1.10.1",
    "Labels": {
        "license": "MIT",
        "name": "fedora",
        "vendor": "Fedora Project",
        "version": "31"
    },
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
        "sha256:a7fc14226e67b8303c32a1287dbea5ea5e240e8476f6e54a2d0ae54b35597848"
    ]
}
$

output

检查JSON。实际上没有任何东西可以帮助我们确定是否信任这个存储库。它“说”它是由Fedora项目(“vendor”:“Fedora Project”)创建的，但我们不知道这是不是真的。我们必须继续验证我们是否相信来源，然后我们才能决定我们是否相信这个东西

有很多关于签名的讨论，然而事实上没有人根据签名去验证容器镜像，大多数人没有使用签名来验证容器图像。他们实际上所做的是依赖于SSL来确定他们信任源，然后推断他们信任容器映像。让我们用这个知识来做一个快速的评估官方的Fedora注册表:

curl -I https://registry.fedoraproject.org

$ curl -I https://registry.fedoraproject.org
HTTP/1.1 200 OK
Date: Wed, 04 Mar 2020 07:27:30 GMT
Server: Apache
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
Upgrade: h2
Connection: Upgrade
Last-Modified: Wed, 04 Mar 2020 06:25:08 GMT
ETag: "16d6b-5a0017b596e04"
Accept-Ranges: bytes
Content-Length: 93547
AppTime: D=203
X-Fedora-ProxyServer: proxy11.fedoraproject.org
X-Fedora-RequestID: Xl9YYgyA8RNWFiIKOTRzqgAACAk
Content-Type: text/html

$

output

 

请注意，SSL证书未能通过测试。这是因为DigiCert root CA证书不在这个CentOS的/etc/pki中。在RHEL和Fedora上，这个证书是默认分发的，registry.fedoraproject.org的SSL证书通过了测试。如果你是在一个Fedora或红帽企业Linux用正确的关键字去测试，输出应该是这样的:

HTTP/2 200 
date: Thu, 25 Apr 2019 17:50:25 GMT
server: Apache/2.4.39 (Fedora)
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
referrer-policy: same-origin
last-modified: Thu, 25 Apr 2019 17:25:08 GMT
etag: "1d6ab-5875e1988dd3e"
accept-ranges: bytes
content-length: 120491
apptime: D=280
x-fedora-proxyserver: proxy10.phx2.fedoraproject.org
x-fedora-requestid: XMHzYeZ1J0RNEOvnRANX3QAAAAE
content-type: text/html

output

即使没有安装root CA证书，我们也可以看出certicate是有效的，并且是由Red Hat管理的，这有一定的帮助:

curl 2>&1 -kvv https://registry.fedoraproject.org | grep subject

 

可视化地验证证书，会让我们对这个注册服务器有一定程度的信任。在真实的场景中，请记住检查这些证书是容器引擎的工作。这意味着系统管理员需要在生产环境中分发适当的CA证书。现在我们已经检查了证书，我们可以安全地从受信任的注册服务器(因为我们知道它是由Fedora/Red Hat管理的)拉出受信任的存储库(因为我们相信Fedora项目是正确构建的)，将其拉取下来:

podman pull registry.fedoraproject.org/fedora

下面看一些更棘手的仓库和注册服务器。

 

二、评估信任—镜像和注册服务器

评估镜像

首先，让我们开始我们已经知道的事情，通常在容器镜像中有一个功能齐全的Linux发行版。 这是因为利用现有的程序包和已经为其创建的依赖关系树很有用。 无论是在裸机上，在虚拟机中还是在容器镜像中运行，都是如此。 同样重要的是，要考虑容器镜像中的更新的质量，频率和易用性。

为了分析质量，我们将利用现有的工具——这是使用基于Linux发行版的容器映像的另一个优点。为了演示，让我们检查来自四种不同Linux发行版的映像—CentOS、Fedora、Ubuntu和Red Hat Enterprise Linux。每一个都将提供不同程度的信息:

 

CentOS

CentOS不提供包更新的勘误表，因此此命令不会显示任何信息。这使得将CVE映射到RPM包非常困难。这反过来更新受CVE影响的包也变得困难。最后，由于缺乏信息，很难对容器映像的质量进行评分。一个基本的解决方法就是更新所有的东西，但即使这样，你也不能100%确定你给哪些CVE打了补丁。

$ podman run -it docker.io/centos:7.0.1406 yum updateinfo
Loaded plugins: fastestmirror
base/7/x86_64                                                                   | 3.6 kB  00:00:00
base/7/x86_64/group_gz                                                          | 165 kB  00:00:00
base/7/x86_64/primary_db                                                        | 6.0 MB  00:00:00
extras/7/x86_64                                                                 | 2.9 kB  00:00:00
extras/7/x86_64/primary_db                                                      | 159 kB  00:00:00
updates/7/x86_64                                                                | 2.9 kB  00:00:00
updates/7/x86_64/primary_db                                                     | 6.7 MB  00:00:00
updateinfo summary done

 

Fedora

Fedora提供有关软件包更新的不错的元数据，但也没有将它们映射到CVE。输出结果在任何一天都会有所不同，但是输出通常是这样的:

$ podman run -it registry.fedoraproject.org/fedora dnf updateinfo
Fedora Modular 31 - x86_64                                             3.3 MB/s | 5.2 MB     00:01
Fedora Modular 31 - x86_64 - Updates                                   2.7 MB/s | 4.0 MB     00:01
Fedora 31 - x86_64 - Updates                                           5.6 MB/s |  21 MB     00:03
Fedora 31 - x86_64                                                      11 MB/s |  71 MB     00:06
Last metadata expiration check: 0:00:01 ago on Wed Mar  4 09:51:55 2020.
Updates Information Summary: available
    5 Security notice(s)
        1 Moderate Security notice(s)
        2 Low Security notice(s)
    3 Bugfix notice(s)
    2 Enhancement notice(s)

 

Ubuntu

Ubuntu提供的信息与Fedora的质量相当，但是同样不容易将更新映射到CVE。这个特定镜像的结果应该总是相同的，因为我们出于演示的目的而故意地拉取一个旧标签。

$ podman run -it docker.io/ubuntu:trusty-20170330 /bin/bash -c "apt-get update && apt list --upgradable"
Ign http://archive.ubuntu.com trusty InRelease
Get:1 http://archive.ubuntu.com trusty-updates InRelease [65.9 kB]
Get:2 http://archive.ubuntu.com trusty-security InRelease [65.9 kB]
Get:3 http://archive.ubuntu.com trusty Release.gpg [933 B]
Get:4 http://archive.ubuntu.com trusty Release [58.5 kB]
Get:5 http://archive.ubuntu.com trusty-updates/main Sources [532 kB]
Get:6 http://archive.ubuntu.com trusty-updates/restricted Sources [6444 B]
Get:7 http://archive.ubuntu.com trusty-updates/universe Sources [288 kB]
Get:8 http://archive.ubuntu.com trusty-updates/main amd64 Packages [1460 kB]
Get:9 http://archive.ubuntu.com trusty-updates/restricted amd64 Packages [21.4 kB]
Get:10 http://archive.ubuntu.com trusty-updates/universe amd64 Packages [671 kB]
Get:11 http://archive.ubuntu.com trusty-security/main Sources [220 kB]
Get:12 http://archive.ubuntu.com trusty-security/restricted Sources [5050 B]
Get:13 http://archive.ubuntu.com trusty-security/universe Sources [126 kB]
Get:14 http://archive.ubuntu.com trusty-security/main amd64 Packages [1032 kB]
Get:15 http://archive.ubuntu.com trusty-security/restricted amd64 Packages [18.1 kB]
Get:16 http://archive.ubuntu.com trusty-security/universe amd64 Packages [377 kB]
Get:17 http://archive.ubuntu.com trusty/main Sources [1335 kB]
Get:18 http://archive.ubuntu.com trusty/restricted Sources [5335 B]
Get:19 http://archive.ubuntu.com trusty/universe Sources [7926 kB]
Get:20 http://archive.ubuntu.com trusty/main amd64 Packages [1743 kB]
Get:21 http://archive.ubuntu.com trusty/restricted amd64 Packages [16.0 kB]
Get:22 http://archive.ubuntu.com trusty/universe amd64 Packages [7589 kB]
Fetched 23.6 MB in 9s (2383 kB/s)
Reading package lists... Done
Listing... Done
apt/trusty-updates 1.0.1ubuntu2.24 amd64 [upgradable from: 1.0.1ubuntu2.17]
apt-utils/trusty-updates 1.0.1ubuntu2.24 amd64 [upgradable from: 1.0.1ubuntu2.17]
base-files/trusty-updates 7.2ubuntu5.6 amd64 [upgradable from: 7.2ubuntu5.5]
bash/trusty-updates,trusty-security 4.3-7ubuntu1.7 amd64 [upgradable from: 4.3-7ubuntu1.6]
busybox-initramfs/trusty-updates,trusty-security 1:1.21.0-1ubuntu1.4 amd64 [upgradable from: 1:1.21.0-1ubuntu1]
dpkg/trusty-updates 1.17.5ubuntu5.8 amd64 [upgradable from: 1.17.5ubuntu5.7]
file/trusty-updates,trusty-security 1:5.14-2ubuntu3.4 amd64 [upgradable from: 1:5.14-2ubuntu3.3]
gcc-4.8-base/trusty-updates,trusty-security 4.8.4-2ubuntu1~14.04.4 amd64 [upgradable from: 4.8.4-2ubuntu1~14.04.3]
gnupg/trusty-updates,trusty-security 1.4.16-1ubuntu2.6 amd64 [upgradable from: 1.4.16-1ubuntu2.4]
gpgv/trusty-updates,trusty-security 1.4.16-1ubuntu2.6 amd64 [upgradable from: 1.4.16-1ubuntu2.4]
ifupdown/trusty-updates 0.7.47.2ubuntu4.5 amd64 [upgradable from: 0.7.47.2ubuntu4.4]
initramfs-tools/trusty-updates 0.103ubuntu4.11 all [upgradable from: 0.103ubuntu4.7]
initramfs-tools-bin/trusty-updates 0.103ubuntu4.11 amd64 [upgradable from: 0.103ubuntu4.7]
iproute2/trusty-updates 3.12.0-2ubuntu1.2 amd64 [upgradable from: 3.12.0-2ubuntu1]
isc-dhcp-client/trusty-updates 4.2.4-7ubuntu12.13 amd64 [upgradable from: 4.2.4-7ubuntu12.8]
isc-dhcp-common/trusty-updates 4.2.4-7ubuntu12.13 amd64 [upgradable from: 4.2.4-7ubuntu12.8]
klibc-utils/trusty-updates 2.0.3-0ubuntu1.14.04.3 amd64 [upgradable from: 2.0.3-0ubuntu1.14.04.2]
kmod/trusty-updates,trusty-security 15-0ubuntu7 amd64 [upgradable from: 15-0ubuntu6]
libapt-inst1.5/trusty-updates 1.0.1ubuntu2.24 amd64 [upgradable from: 1.0.1ubuntu2.17]
libapt-pkg4.12/trusty-updates 1.0.1ubuntu2.24 amd64 [upgradable from: 1.0.1ubuntu2.17]
libc-bin/trusty-updates,trusty-security 2.19-0ubuntu6.15 amd64 [upgradable from: 2.19-0ubuntu6.11]
libc6/trusty-updates,trusty-security 2.19-0ubuntu6.15 amd64 [upgradable from: 2.19-0ubuntu6.11]
libdb5.3/trusty-updates,trusty-security 5.3.28-3ubuntu3.1 amd64 [upgradable from: 5.3.28-3ubuntu3]
libdrm2/trusty-updates,trusty-security 2.4.67-1ubuntu0.14.04.2 amd64 [upgradable from: 2.4.67-1ubuntu0.14.04.1]
libexpat1/trusty-updates,trusty-security 2.1.0-4ubuntu1.4 amd64 [upgradable from: 2.1.0-4ubuntu1.3]
libffi6/trusty-updates,trusty-security 3.1~rc1+r3.0.13-12ubuntu0.2 amd64 [upgradable from: 3.1~rc1+r3.0.13-12ubuntu0.1]
libgcrypt11/trusty-updates,trusty-security 1.5.3-2ubuntu4.6 amd64 [upgradable from: 1.5.3-2ubuntu4.4]
libgnutls-openssl27/trusty-updates,trusty-security 2.12.23-12ubuntu2.8 amd64 [upgradable from: 2.12.23-12ubuntu2.7]
libgnutls26/trusty-updates,trusty-security 2.12.23-12ubuntu2.8 amd64 [upgradable from: 2.12.23-12ubuntu2.7]
libklibc/trusty-updates 2.0.3-0ubuntu1.14.04.3 amd64 [upgradable from: 2.0.3-0ubuntu1.14.04.2]
libkmod2/trusty-updates,trusty-security 15-0ubuntu7 amd64 [upgradable from: 15-0ubuntu6]
libmagic1/trusty-updates,trusty-security 1:5.14-2ubuntu3.4 amd64 [upgradable from: 1:5.14-2ubuntu3.3]
libplymouth2/trusty-updates 0.8.8-0ubuntu17.2 amd64 [upgradable from: 0.8.8-0ubuntu17.1]
libpng12-0/trusty-updates,trusty-security 1.2.50-1ubuntu2.14.04.3 amd64 [upgradable from: 1.2.50-1ubuntu2.14.04.2]
libprocps3/trusty-updates,trusty-security 1:3.3.9-1ubuntu2.3 amd64 [upgradable from: 1:3.3.9-1ubuntu2.2]
libpython3.4-minimal/trusty-updates,trusty-security 3.4.3-1ubuntu1~14.04.7 amd64 [upgradable from: 3.4.3-1ubuntu1~14.04.5]
libpython3.4-stdlib/trusty-updates,trusty-security 3.4.3-1ubuntu1~14.04.7 amd64 [upgradable from: 3.4.3-1ubuntu1~14.04.5]
libsqlite3-0/trusty-updates,trusty-security 3.8.2-1ubuntu2.2 amd64 [upgradable from: 3.8.2-1ubuntu2.1]
libssl1.0.0/trusty-updates,trusty-security 1.0.1f-1ubuntu2.27 amd64 [upgradable from: 1.0.1f-1ubuntu2.22]
libstdc++6/trusty-updates,trusty-security 4.8.4-2ubuntu1~14.04.4 amd64 [upgradable from: 4.8.4-2ubuntu1~14.04.3]
libtasn1-6/trusty-updates,trusty-security 3.4-3ubuntu0.6 amd64 [upgradable from: 3.4-3ubuntu0.4]
libudev1/trusty-updates,trusty-security 204-5ubuntu20.31 amd64 [upgradable from: 204-5ubuntu20.24]
login/trusty-updates,trusty-security 1:4.1.5.1-1ubuntu9.5 amd64 [upgradable from: 1:4.1.5.1-1ubuntu9.4]
logrotate/trusty-updates 3.8.7-1ubuntu1.2 amd64 [upgradable from: 3.8.7-1ubuntu1]
module-init-tools/trusty-updates,trusty-security 15-0ubuntu7 all [upgradable from: 15-0ubuntu6]
mountall/trusty-updates 2.53ubuntu1 amd64 [upgradable from: 2.53]
multiarch-support/trusty-updates,trusty-security 2.19-0ubuntu6.15 amd64 [upgradable from: 2.19-0ubuntu6.11]
ntpdate/trusty-updates,trusty-security 1:4.2.6.p5+dfsg-3ubuntu2.14.04.13 amd64 [upgradable from: 1:4.2.6.p5+dfsg-3ubuntu2.14.04.10]
passwd/trusty-updates,trusty-security 1:4.1.5.1-1ubuntu9.5 amd64 [upgradable from: 1:4.1.5.1-1ubuntu9.4]
perl/trusty-updates,trusty-security 5.18.2-2ubuntu1.7 amd64 [upgradable from: 5.18.2-2ubuntu1.1]
perl-base/trusty-updates,trusty-security 5.18.2-2ubuntu1.7 amd64 [upgradable from: 5.18.2-2ubuntu1.1]
perl-modules/trusty-updates,trusty-security 5.18.2-2ubuntu1.7 all [upgradable from: 5.18.2-2ubuntu1.1]
plymouth/trusty-updates 0.8.8-0ubuntu17.2 amd64 [upgradable from: 0.8.8-0ubuntu17.1]
procps/trusty-updates,trusty-security 1:3.3.9-1ubuntu2.3 amd64 [upgradable from: 1:3.3.9-1ubuntu2.2]
python3.4/trusty-updates,trusty-security 3.4.3-1ubuntu1~14.04.7 amd64 [upgradable from: 3.4.3-1ubuntu1~14.04.5]

Ubuntu Output

 

Red Hat Enterprise Linux

遗憾的是，我们没有在命令行上分析Red Hat通用基础映像(UBI)所必需的活动Red Hat订阅，但是如果在RHEL或OpenShift上运行，输出应该如下所示:

RHSA-2019:0679 Important/Sec. libssh2-1.4.3-12.el7_6.2.x86_64
RHSA-2019:0710 Important/Sec. python-2.7.5-77.el7_6.x86_64
RHSA-2019:0710 Important/Sec. python-libs-2.7.5-77.el7_6.x86_64

$ podman run -it registry.access.redhat.com/ubi7/ubi:7.6-73 yum updateinfo security
Loaded plugins: ovl, product-id, search-disabled-repos, subscription-manager
This system is not receiving updates. You can use subscription-manager on the host to register and assign subscriptions.
ubi-7                                                                           | 3.8 kB  00:00:00
ubi-7-rhah                                                                      | 3.7 kB  00:00:00
ubi-7-rhscl                                                                     | 3.8 kB  00:00:00
(1/9): ubi-7/x86_64/group                                                       |  124 B  00:00:00
(2/9): ubi-7/x86_64/updateinfo                                                  |   92 B  00:00:01
(3/9): ubi-7-rhah/x86_64/group                                                  |  124 B  00:00:00
(4/9): ubi-7-rhah/x86_64/updateinfo                                             |   92 B  00:00:01
(5/9): ubi-7/x86_64/primary_db                                                  | 797 kB  00:00:01
(6/9): ubi-7-rhscl/x86_64/group                                                 |  124 B  00:00:00
(7/9): ubi-7-rhscl/x86_64/updateinfo                                            |   92 B  00:00:01
(8/9): ubi-7-rhah/x86_64/primary_db                                             | 2.5 kB  00:00:01
(9/9): ubi-7-rhscl/x86_64/primary_db                                            | 218 kB  00:00:01
updateinfo list done

实际输出

注意RHSA-:列——这表示勘误表和它的importnace级别。此勘误表可用于将更新映射到特定的CVE，从而使您和您的安全团队确信容器镜像已为任何特定的CVE打过补丁。即使没有Red Hat订阅，我们也可以通过查看Red Hat容器Cataog并使用Contianer健康指数来分析Red Hat镜像的质量:

点击 Red Hat Enterprise Universal Base Image 7 可以看到类似下面的视图：

 

 

评估注册表

现在，我们已经看了一些容器镜像，我们将开始看看他们从哪里来，他们是如何构建的-我们将评估四个注册服务器- Fedora, podmanHub, Bitnami和Red Hat Container Catalog:

 

Fedora Registry

https://registry.fedoraproject.org/ 

Fedora注册表提供了很基础的功能。 它是由Fedora项目操作的，因此安全性应该与您下载的ISO非常相似。 也就是说，没有较旧版本的镜像，并且实际上没有针对镜像的修补，更新或发布频率制定明确的政策。

 

podmanHub

https://hub.podman.com/_/centos/

podmanHub为许多不同的软件提供“官方”镜像，包括CentOS、Ubuntu、Wordpress和php。也就是说，“官方”的意思并没有标准的定义。每个存储库似乎都有自己的流程、规则、时间线、生命周期和测试。对于官方镜像提供给最终用户的内容，确实没有共同的理解。用户必须自己评估每个存储库，并确定他们是否相信它以任何有意义的方式连接到上游项目。

 

Bitnami

https://bitnami.com/containers

与podmanHub相似，没有太多信息以任何有意义的方式将这些目录链接到上游项目。 甚至没有清楚地知道哪些标签可用或应该使用。 再次重申，如果没有版本信息的生命周期保证，则政策信息和用户几乎只能在GitHub存储库中进行筛选，以了解它们的构建方式。 您几乎只剩下相信Bitnami以您想要的方式构建容器...

 

Red Hat Container Catalog

https://access.redhat.com/containers

Red Hat容器目录的设置方式与几乎所有其他注册服务器都完全不同。每一存储库都有大量的信息。仔细查看并注意该特定镜像如何与警告相关联。对于本练习，我们有意地查看具有已知漏洞的旧镜像。这是因为容器的镜像像奶酪一样，而不是像葡萄酒。信任是长期的，旧的容器镜像就像服务器一样，很少或从来没有打过补丁。

现在看看每个可用标记的容器健康指数评分。注意，标签越新，评分等级越高。Red Hat容器目录和容器健康指数清楚地向您显示新镜像的缺陷较少，因此具有更好的字母等级。要完全理解评分标准，请参阅知识库文章。这是由Red Hat容器目录提供的一个完全独特的功能，因为将容器镜像绑定到CVE会生成容器映像勘误表。

 

三、分析存储和图形驱动程序

 当拉取一个镜像时，每一层都会缓存到本地，并映射到一个本地文件共享系统中-通常是overlay2或devicemapper。这有几个含义。首先，这意味着在本地缓存容器镜像在历史上一直是根操作。其次，如果您拉取一个镜像，或提交一个新层，其中包含密码，系统中的任何人都可以看到它，即使您从未将其推到注册服务器。

 

下面来看一下docker和podman在存储方面的区别：

$ docker info 2>&1 | grep -E ‘Storage | Root‘
Storage Driver: devicemapper
Docker Root Dir: /var/lib/docker

docker将容器镜像存储在 /var/lib/docker 中，并使用 devicemapper的存储驱动

$ podman info | grep -A3 Graph
  GraphDriverName: overlay
  GraphOptions: null
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"

podman使用相同的OCI兼容，docker兼容镜像，但是使用不同的存储驱动：overlay 和不同的存储位置：/var/lib/containers/storage

d-type是什么？它作为一个文件系统选项必须支持overlay2作为一个容器镜像和运行容器的后备存储能够正常工作.

 

无论是podman还是docker还是存在的其他容器引擎，镜像层被一个接一个的映射到某种存储，成为devicemapper的thinp快照，或者是overlay2的目录。

这将对你从一个注册库转移到另一个注册库有影响，首先必须先拉取缓存在本地，然后打上你想在新注册库中的URL，命名空间，仓库和标签，最终将其推送到远端。

这是一个混乱的过程，后面将会学习名为Skopeo的工具，它使这项工作变得更加容易。