伸手黨的容器鏡像加固流程

人在江湖飄，哪能不挨刀

說了好幾期 CIS 之類的運行時安全問題，K8s 在運行過程當中，還有個常見的安全威脅就是鏡像漏洞，很多同窗都有在實施過程當中由於鏡像漏洞問題被吊打的經驗，今天就結合我的經驗，說說鏡像漏洞修復的通常流程。

這裏主要指的是第三方鏡像的修復過程，Scratch 不在此列。

修復任務分析

一般掃描報告會明確指明確切的問題源頭、相關軟件包、問題版本、修復版本等，首先要根據報告判斷修復的目標。修復目標並不必定是固定的，有些狀況下可能僅須要修復公開的高危漏洞，有些可能要求更多。

咱們都知道，容器鏡像是個分層結構，底層一般由操做系統（例如 debian:buster-slim）或者特定運行時（例如 openjdk:16）構成；另外可能構建應用程序，或者直接經過 COPY/ADD 的方式加入應用程序；另外還會經過 CMD、ENV 等指令設置運行環境等。軟件漏洞多發於底層和應用程序層，所以這裏須要根據掃描報告，確認咱們的修復目標。

軟件配置問題也可能形成漏洞，能夠另行講解。

應用層漏洞

若是要修復的問題是處於應用層，就要判斷該鏡像是否爲官方鏡像，若是答案是確定的，則能夠直接更新官方鏡像，一般同一個大版本下的小版本更新，都是兼容的，能夠更新以後直接進行測試和複查。

若是官方沒有針對性的修復，或者鏡像並未更新，就可能須要本身構建鏡像了。

若是是開源軟件，強烈建議提交 Issue 或者 PR

基礎層漏洞

若是是基礎層漏洞，除了能夠像應用層修復同樣，檢查版本更新以外，還有另外一個選項，就是更換不一樣的基礎層，例如從 Debian 更換爲 Ubuntu，這種方式對於 all-in-one 形式的應用（例如大多數用 golang 構建的應用）尤爲有效，若是應用程序依賴衆多，就不合適了。另外衆所周知，Alpine 和咱們經常使用的發行版差別較大，所以也不太合適直接切換。

鏡像構建

是否是就一個 docker build 就能夠了？多數時候是的。不過要分紅幾種狀況。

• 有 Dockerfile 的狀況

• 官方已經發布二進制物料：這種狀況經過修改 Dockerfile 加入更新的二進制文件以後，執行 docker build 便可。

• 官方未發佈二進制物料：這種就須要根據源碼進行構建，而後再生成 Docker 鏡像。

• 沒有 Dockerfile 的狀況

• 有的軟件源碼中經過 Makefile 等方式提供了從二進制到鏡像的構建方法，一般須要在 README.md 或者 BUILD.md 中查找線索。

• 更換底層的狀況，一般須要本身照貓畫虎，從新編寫 Dockerfile。

• 還有一種比較尷尬的狀況——有二進制物料，可是沒 Dockerfile，這種我一般會使用 docker cp->docker commit 的不入流方式。

• 另一種尷尬狀況就是，官方只提供了 Docker 鏡像，可是咱們想要換掉基礎層，這種狀況和上面相似，用 docker cp 把官方鏡像中的應用文件複製出來便可。

複測

在完成修復步驟以後，能夠針對性地進行復測，查看修復狀況，循環往復直到完成目標爲止。

本文分享自微信公衆號 - 僞架構師（fake-architect）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。