容器镜像签名思考

解决什么问题

1.镜像在流转（镜像打包，镜像推送到仓库，镜像从仓库拉取部署）中被污染

2.仓库被攻破，镜像被攻击者上传新镜像，替代我们的拉取流程

3.镜像仓库地址被劫持

4.镜像仓库账号泄露，被盗用

5.节点被攻破，使用docker login后的凭据来上传镜像(需验证)

攻击场景

1.客户使用pull always，我们拥有harbor仓库密码，直接上传我们的恶意镜像，既拉取最新镜像

2.客户使用pull justNotExist，并且通过镜像名字+tag方式拉取，我们将某个镜像的name+tag替换后即可完成攻击

3.3.客户使用pull justNotExist，并且通过@sha256拉取，替换镜像内容（取决于digest算法，既它计算哪些内容）。（待验证）--经过研究，在拉取过程中会一步步校验digest，但不确定是否还有更多攻击点

4.客户使用pull justNotExist，并且通过镜像名字+tag方式拉取或者@sha256拉取，我们替换掉harbor底层镜像来完成攻击，既直接修改harbor保存的镜像（数据库中的）来完成攻击。（待验证）--经过研究，在拉取过程中会一步步校验digest，但不确定是否还有更多攻击点

4.客户使用pull justNotExist，并且通过镜像名字+tag方式拉取或者@sha256拉取，我们替换掉流量侧来进行攻击，既将拉取过程中的镜像替换。经过验证后，docker会在pull流程对拉取的层做校验。对于这样的攻击是失效的。

云原生下的devops流程

1.制作镜像