你知道你的Docker镜像里有什么吗？Buildpacks知道。

CNCF

发布于 2019-12-04 15:36:51

1.1K0

发布于 2019-12-04 15:36:51

文章被收录于专栏：CNCF

作者：Emily Casey

你不能修补一个你不知道你有的漏洞。这就是为什么了解Docker镜像中的内容是确保其安全性的第一步。幸运的是，任何使用Cloud Native Buildpacks构建的镜像都包含元数据，你不仅可以使用这些元数据来确定镜像包含什么，还可以确定每个层中包含什么以及如何创建镜像。

使用Pack CLI的pack build命令创建的任何镜像也可以用inspect-image命令检查，如下所示：

https://github.com/buildpack/pack

$ pack inspect-image ekcasey/myimage
Inspecting image: ekcasey/myimage
REMOTE:
Stack: io.buildpacks.stacks.bionic
Base Image:
  Reference: index.docker.io/cloudfoundry/run@sha256:8de6ef35195a6ebb4875cfb2ab5dfb4334c7bef85425318739a6c6bfc4edb202
  Top Layer: sha256:9335faa48c88fc9f7f831f86e41ba979fa402bc715671b11d63c4f3eb4f69458
…
Run Images:
  cloudfoundry/run:base-cnb
Buildpacks:
  ID                              VERSION
  org.cloudfoundry.openjdk        v1.0.48
  org.cloudfoundry.jvmapplication v1.0.66
  org.cloudfoundry.springboot     v1.0.88
LOCAL:
...

这个示例输出告诉我们，镜像是使用三个构建包（buildpack）构建的。它还告诉我们用于创建最终镜像的堆栈ID和运行镜像的标记。与此信息一起包含的是堆栈“顶层”的引用，你可以使用它将基础镜像与buildpack创建的层分隔开。

此信息是Pack用于执行其rebase命令的内容，其中buildpack创建的层用于创建具有更新堆栈的新镜像，而无需运行构建。

镜像上的元数据还包含关于每个层内部的信息。我们可以通过提供——bom选项来查看它，它为镜像发出一个材料清单。这些信息来自构建包创建的构建计划（build plan）。因为这些信息存储在镜像的配置层中，可以很容易地读取它们，而不必从注册表中提取整个镜像。

https://github.com/buildpack/spec/blob/master/buildpack.md#build-plan-toml

$ pack inspect-image ekcasey/myimage --bom | jq .remote
[
  {
  "buildpack": {
    "id": "org.cloudfoundry.openjdk",
    "version": "v1.0.48"
  },
  "metadata": {
    "licenses": [
      {
        "type": "GPL-2.0 WITH Classpath-exception-2.0",
        "uri": "https://openjdk.java.net/legal/gplv2+ce.html"
      }
    ],
    "name": "OpenJDK JRE",
    "sha256": "2f08c469c9a8adea1b6ee3444ba2a8242a7e99d87976a077faf037a9eb7f884b",
    "uri": "https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.5%2B10/OpenJDK11U-jre_x64_linux_hotspot_11.0.5_10.tar.gz"
    },
    "name": "openjdk-jre",
    "version": "11.0.5"
  },
  ...

在这个条目中，我们可以看到这个镜像包含OpenJDK JRE版本11.0.5。我们还可以看到与此JRE关联的许可证和从中提取的URI。

另一个示例材料清单条目包含的信息包括类路径和已安装的依赖项。

$ pack inspect-image ekcasey/myimage --bom | jq .remote
  ...
  {
    "buildpack": {
      "id": "org.cloudfoundry.springboot",
      "version": "v1.0.88"
    },
    "metadata": {
      "classes": "BOOT-INF/classes/",
      "classpath": [
        "/workspace/BOOT-INF/classes",
        "/workspace/BOOT-INF/lib/attoparser-2.0.5.RELEASE.jar",
        "/workspace/BOOT-INF/lib/classmate-1.4.0.jar",
        "/workspace/BOOT-INF/lib/hibernate-validator-6.0.18.Final.jar",
        "/workspace/BOOT-INF/lib/jackson-annotations-2.9.10.jar",
        ...
      ],
      "lib": "BOOT-INF/lib/",
      "start-class": "io.buildpacks.example.sample.SampleApplication",
      "version": "2.1.10.RELEASE"
    },
    "name": "spring-boot",
    "version": ""
  },
  ...

这些信息可以手工使用，或者更有可能与自动化一起使用，以确保遵从性、扫描易受攻击的依赖项，或者生成用于开放源码许可公开的文件。

Buildpacks使用结构化数据来报告镜像的确切内容，而不是依赖于从文件系统收集信息的外部工具。这使得它们非常适合具有严格遵从性或安全性需求的组织，而不会迫使开发人员在工具上做出妥协。Buildpacks通过将开发人员从诸如生成材料清单之类的关注点中分离出来，实现了易用性和可操作性之间的平衡。

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2019-11-28，如有侵权请联系 cloudcommunity@tencent.com 删除

https