docker image digest

2020-09-23  本文已影响0人  张培_

Background

最近在项目上工作的时候,发现Dockerfile中引入的镜像长这个样子:

FROM node:12.18.4-alpine@sha256:757574c5a2102627de54971a0083d4ecd24eb48fdf06b234d063f19f7bbc22fb

EXPOSE 3000

根据我的认知,一个docker image应该是这样组成的:

[repository:tag] 
or
repository

那么@之后是什么呢?

@之后就是所谓的digest

What is digest?

根据官网给出的定义是:

使用V2以及V2以上格式的镜像将会有一个叫做digest的内容可寻址标识符。

根据定义来看,这个digest其实就是就是根据镜像内容产生的一个ID,官网上说,只要用于产生这个image的输入不变,那么digest就是可以预测的,换句话说只要镜像的内容不变digest也不会变。

当你使用docker build构建镜像的时候,docker会根据内容产生一个digest,比如使用下面这个指令就会输出这个镜像的digest

$ docker build --no-cache -q .

当你使用docker push将这个镜像push到register,这个digest的信息也会跟着镜像被一起存储。

但你使用docker pull将这个镜像pull到本地的时候,你可以将这个image的repository、tag、digest全部带上,唯一的确定这个镜像。

Why we use digest?

当你从网络上下载内容某一个包,如果你想要保证下载的包是完整性并且没有被恶意篡改过,常用的方式就是根据这个包的内容,为这个包生成加密哈希串。可以通过对比这个加密哈希串来保证内容没有被改变过。

这个哈希串就是content adressable identifier(内容可识别标识符).

验证方式可以是:

想象一个场景:

你向docker-hub中push了一个镜像my-app:v1.0.0,但是你的Docker Hub credentials被人盗取了,这个人可能会将一段恶意代码植入了你的镜像,并且使用带有恶意代码的镜像覆盖了v1.0.0这个镜像版本。

但是你的production,只是pull了my-app:v1.0.0,并且运行这个镜像,并没有考虑内容是否和以前一样,这时候你的production可能那个已经被恶意代码侵害了。

那么在这种场景下,docker digest能如何帮助我们躲避这种风险呢?

如果你的production不只是定义了版本,而是pull下了这样的镜像
my-app@sha256:saklfjdksajfkdsajfkladsjlfkjdskl
也就是将digest(内容id)带上, docker会帮助我们:

The pros of docker Digest

上一篇 下一篇

猜你喜欢

热点阅读