Docker 镜像安全

镜像安全的最佳实践

---

在开发的时候，应用要去保障安全，普通的非加密的HTTP协议就不安全，因为数据传输是明文的，可以被别人看见的，没有认证鉴权的服务就是不安全的。

我有应用装到容器里面来了，那么为了保证容器镜像的安全，我就要去看除了应用本身是否安全，我还要看应用所依赖的中间件是否安全，我还要看它基础镜像，比如一个操作系统的话，我还要知道这个操作系统安装的这些包是不是安全的。

构建指令问题

密钥和token：容器镜像是到处分发的，大家可以直接将容器镜像拉取下来，一解压就知道容器里面包含了哪些信息，因为它就是一个tar包，解开来之后就可以看到里面所有的内容，这个文件其实就是相当于明文送给大家了，这就相当于将用户名和密码给所有人了。

应用依赖

容器运行的时候需要的所有依赖包，都应该在容器镜像里面同时构建进来。如果是依赖的基础服务本身有安全问题，那么这个容器镜像也是不安全的。

比如是一个java应用，引用了log4j的library，那么其实你的应用本身就有非常大的漏洞。

或者你的应用长时间不去更新，之前有些安全的保障手段，随着时间的推移就变的不安全了，那么这个时候容器镜像也会面临风险，比如openssl 1.0，随着时间的推移都被证明不安全，其实都是有安全漏洞和版本问题才会向前演进。

如果应用长时间不更新还是基于老的版本这些协议，它也会有一定的安全风险。

文件问题

当我们将文件加载到容器镜像里面的时候，如果这个文件自身有安全漏洞，那么本身也是有问题的。

容器镜像都是分层的，一旦一个文件的层级确定好之后，你在上面做任何的修改，也只是在上面增加新的层。

如果文件里面放了用户名和密码，一旦image镜像推出去，那么用户名密码就公之于众了，再去rm是没有意义的。

镜像扫描(Vulnerability Scanning)

---

镜像策略准入控制

---

在kubernetes集群里面，如何和镜像扫描结果产生一个相关性，这就涉及到准入控制策略了。

在准入的阶段分为了mutating和validating对吧，区别是一个变形和一个校验，在validing其中有很多的plugin，其中有一个叫imagepolicyadmit的plugin，这个plugin就是用来校验image策略结果的这样一个plugin，它本身会支持一个webhook，所以要将镜像扫描结果和kubernets的准入策略做好整合之后，那么就可以在用户建立pod的时候来决定pod镜像是否安全，是不是应该放它过去。

上面图在镜像准入，就有各种各样的准入的plugin，其中有个是镜像策略就是imagepolicy，它会先收集所有的pod的镜像，然后让这个准入控制器去查询镜像安全的状态，如果安全就准入，不安全就拦截。

扫描镜像

---

首先从镜像仓库将文件拉取下来，然后解析镜像的原数据，然后解压镜像的每一个文件层，因为它分原数据和blob，所以会去对两个部分分别去做校验，它会怎么去做校验呢？它会去提取这个文件，文件解压了之后每一层所依赖的包，可运行程序，文件列表，这些文件内容全部进行扫描，然后它会将扫描结果和CVE的字典，以及我们自定义的安全策略字典做匹配，来确定这个镜像是否是安全的。

镜像扫描服务

---

anchore的能力是比较全的，Clair是针对harbor的做了有个很好的支撑，在harbor里面，所以在harbor里面可以在安装的时候就直接选择安装Clair，在镜像仓库里面就直接可以enable Clair，这样的话所有上传到harbor的镜像就可以被这个镜像仓库扫描到。

Clair架构

---

前端也是HTTP interface，就类似于比如说嵌入在harbor里面的一个界面，它也会有个通知机制，镜像的扫描结果要告诉你，通过select channel或者发邮件告诉你，这个镜像扫描没过等等。这些地方的通知要有地方存储。

下面就是Clair的核心组件，我们这里也维护了一些违规的漏洞表，它存储在这里面，然后有image下下来之后，它会去分析每一个层级，然后和自己的library去做对比，说发现有没有漏洞，如果有漏洞的话就通知用户。