鏡像安全的最佳實踐
在開發的時候，應用要去保障安全，普通的非加密的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的鏡像就可以被這個鏡像倉庫掃描到。