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去做對比，說發現有沒有漏洞，如果有漏洞的話就通知用戶。
總結
以上是生活随笔為你收集整理的Docker 镜像安全的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： access前端连接mysql_用jav
- 下一篇： IDEA如何上传java项目到githu