生產中的12種容器映象掃描最佳實踐

現在很多團隊面臨着這麼一個挑戰：如何在不減慢應用交付速度的情況下，管理好安全風險。有種方法可以解決該問題，就是採用安全的 DevOps 工作流程。

安全的DevOps(也稱爲DevSecOps)會在從開發到生產的整個應用程式宣告週期中提供安全性以及監控功能，幫助我們交付安全、穩定和高效能的應用程式。如果我們把該工作流程插入現有的工具鏈中，可以爲DevOps、開發人員和安全團隊最大程度地提高效率。

DevSecOps五個基本工作流程包括映象掃描、執行安全、合規性、Kubernetes和容器的監控以及應用程式和雲服務監控。

映象掃描是嵌入到DevSecOps工作流程中的一項關鍵功能。作爲第一道防線，它可以幫助我們在漏洞被利用之前檢測到漏洞並阻止，另外，它還易於實現並可自動化。本文將介紹多個映象掃描的最佳實踐和技巧，幫助大家採用有效的容器映象掃描策略。

什麼是容器映象掃描

映象掃描是指分析容器映象的內容和構建過程，以檢測安全問題、漏洞或錯誤實踐。

我們可以從多個 Feed(NVD、Alpine、Cannonical等)中收集"通用漏洞披漏(CVE)"資訊，以檢查映象是否容易受到攻擊，其中有些還提供了開箱即用的掃描規則，以查詢最常見的安全問題和錯誤實踐。

映象掃描可以輕鬆被整合到DevSecOps工作流程的多個步驟中，例如整合到CI/CD管道中，阻止漏洞到達註冊表;整合在註冊表中，防止第三方映象中的漏洞;也可以在執行時整合，防止新發現的CVE。

當我們遵循並執行最佳實踐時，映象掃描可確保團隊不會因部署應用程式而導致交付速度變慢。現在讓我們深入瞭解這 12 種映象掃描最佳實踐。

12 種映象掃描最佳實踐

1.將映象掃描嵌入到 CI/CD 管道中

構建容器映象時，我們應格外小心，並在映象發佈之前對其進行掃描。我們可以在DevOps工作流程中使用已經構建好的CI/CD管道，並增加映象掃描的步驟。

CI/CD管道上映象掃描的架構如下:

測試和構建映象後，我們不必將映象推播到生產庫，可以先推播到暫存庫，然後執行映象掃描工具。這些工具通常會返回一份報告，列出發現的問題，併爲每個問題分配不同級別的嚴重性。在CI/CD管道中，我們可以檢查這些映象掃描結果，並在出現任何嚴重問題時停止構建。

有一點要記住，自動化是最關鍵的，這是DevOps的核心概念，也適用於保護 DevOps。通過自動化 CI/CD 管道中的安全性檢查，我們可以在漏洞進入註冊表之前就將其捕獲，這樣就不會給漏洞任何機會。

2.採用 inline 掃描以保護隱私

在上一步中，我們看到了 CI/CD 管道中的映象掃描與臨時註冊表的關係，但如果映象包含一些錯誤憑證該怎麼辦？它們可能會出現錯誤，最終導致數據泄漏。所以更進一步，我們可以實施 inline 映象掃描，不使用暫存庫，直接從 CI/CD 管道掃描映象。

使用 inline 映象掃描，它會僅掃描發送到掃描工具的元數據，從而幫助保護隱私。

使用 inline 映象掃描，可以在 CI/CD 管道內掃描映象。程式碼推播後，在不離開 CI/CD 管道的情況下即可構建並掃描映象。映象元數據會被髮送到映象掃描器，然後結果會發送回 CI/CD 管道。如果該映象遵循安全策略，那它將被推播到生產映象儲存庫。

3.在註冊表中執行映象掃描

開始實施映象掃描時，要將其嵌入到註冊表中，這是第一步。

通常，我們會有一個用於發佈映象的專用儲存庫，還有一些用於從第三方下載映象的公共儲存庫。我們需要掃描這兩個儲存庫的映象。

我們部署的所有映象都將從註冊表中提取。通過在那裏掃描映象，我們至少可以確保它們在執行之前已經被掃描過了。

4.使用 Kubernetes 準入控制器

如果想在使用映象之前先對其進行檢查，以防止將未掃描或易受攻擊的映象部署到叢集上，我們可以使用準入控制器。

Kubernetes準入控制器是強大的Kubernetes原生功能，可以幫助我們自定義在叢集上允許執行的內容。在對請求進行身份驗證和授權之後，在物件持久化儲存etcd之前，準入控制器可以攔截並處理對Kubernetes API的請求。

將Deployment的建立請求發送到Kubernetes後，準入控制器將呼叫Webhook併發送映象元數據。映象掃描器會將掃描結果發揮準入控制器，準入控制器在掃描通過後纔會保留Deployment。

掃描工具通常會提供一個驗證Webhook，該Webhook可以按需觸發映象掃描，然後返回驗證決策。

準入控制器可以在排程映象之前呼叫此Webhook。Webhook返回的安全性驗證決策將傳回API伺服器，該伺服器會回覆 回復原始請求者，並且僅在映象通過檢查後纔將物件持久儲存在etcd數據庫中。不過，該決定是由映象掃描器做出的，並沒有任何叢集中有關情況的上下文(context),這裏我們可以使用OPA改進。

Open Policy Agent(OPA)是一種開放原始碼通用策略引擎，它是一種叫Rego的高階宣告性語言編寫的。OPA關鍵思想之一是將決策與政策執行脫鉤。

使用OPA，我們可以在Kubernetes叢集而不是映象掃描器中做出準入決定，這樣就可以在決策過程中使用叢集資訊，例如名稱空間、Pod元數據等。

5.固定的映象版本

有時，我們掃描的映象與在 Kubernetes 叢集中部署的映象不同，例如在使用可變標籤（比如「latest」或「staging」）時，就可能會發生這種情況。此類標籤會不斷更新版本，從而使得我們很難知道最新的掃描結果是否仍然有效。

標籤「:latest」會指向映象的最新版本，除了最後一個版本外，其他所有版本均會被掃描。

使用可變標籤可能會導致使用同一個映象卻部署了不同版本容器的情況。除了掃描結果帶來的安全問題外，這可能還會導致難以偵錯。

爲了代替 ubuntu:focal，我們應該儘可能使用不可變標籤，例如 ubuntu:focal-20200423。

這裏要記住，version 標籤（對於某些映象）往往會進行較小的、不間斷的更新，因此確保可重複性唯一的選擇就是使用實際映象 ID：

ubuntu:@sha256:d5a6519d9f048100123c568eb83f7ef5bfcad69b01424f420f17c932b00dea76

這裏可能有點超出鏡像掃描最佳實踐的範圍，但我們要知道，這些不僅會影響 Dockerfiles 中的 FROM 命令，還會影響 Kubernetes Deployment 檔案以及幾乎所有放置映象名稱的地方。

從映象掃描的角度來看，我們能做什麼？我們可以通過結合使用 Kubernetes 準入控制器、映象掃描器和 OPA 引擎來實施此策略。

6.掃描操作系統漏洞

作爲一般的映象掃描最佳實踐，請牢記這一點:"映象越輕越好",越輕的映象意味着更快的構建、更快的掃描以及更少的潛在漏洞依賴性。

新的Docker映象通常是在現有基礎映象的基礎上構建的，或在現有基礎映象之上新增一層。該基礎映象是由Dockerfile映象中的FROM語句定義的，這樣的分層的體系結構設計，可以在最常見的任務中節省大量時間。例如，在映象掃描時，我們只需要掃描一次基礎映象。如果父映象易受攻擊，那麼在該父映象之上構建的任何其他映象也是易受攻擊的。

WordPress和PHP映象基於Apache，而Apache基於Ubuntu映象。如果Apache上存在漏洞，那麼WordPress和PHP映象都將容易受到攻擊。

即使我們沒有在映象中引入新漏洞，但基礎映象中的漏洞也很容易讓我們受到攻擊。這就是爲什麼掃描工具應主動跟蹤已知漏洞檔案的漏洞源，並在我們使用其中的漏洞時進行通知。

7.使用 distroless 映象

distroless 映象僅允許我們將應用程式及其依賴項打包在輕量級容器映象中。將執行時容器中的內容嚴格限製爲必需內容可以最大程度地減少攻擊面。另外，它還可以改善掃描器的訊雜比(例如CVE)，並根據需要減輕負擔。

以下範例顯示了用於"Hello world"應用程式的Dockerfile，該應用程式在Ubuntu和Distroless上執行。

FROM ubuntu:focal

COPY main /

ENTRYPOINT ["/main"]

對其進行掃描後，我們發現了24個操作系統漏洞，其中兩個嚴重程度爲中。這樣一個簡單的應用程式，影響大小居然有77.98MB這麼大。

現在，基於distroless映象的同一應用程式:

FROM gcr.io/distroless/static-debian10

COPY main /

ENTRYPOINT ["/main"]

現在，我們只發現了兩個可以忽略不計的漏洞，此外，映象大小減小到只有6.93MB,這更適合此應用程式。

這表明，distroless容器沒有任何不必要的程式包，這些程式包可能導致更多的漏洞而被利用。

8.掃描第三方庫中的漏洞

應用程式使用了大量的庫，以至於這些庫最終提供的程式碼行比團隊編寫的實際程式碼還多。這意味着我們不僅需要知道程式碼中的漏洞，還需要知道其所有依賴項中的漏洞。

不過掃描器檢測操作系統漏洞的相同漏洞源，會跟蹤這些漏洞，但並非所有工具都能像掃描映象中的庫一樣深入，因此請確保映象掃描器已深入挖掘並向我們警告這些漏洞。

9.優化映象層順序

謹慎使用Dockerfile中的RUN命令可以進一步優化映象。RUN命令的順序可能會對最終映象產生重大影響，因爲它決定了映象層的順序。

我們可以首先防止較大的層(通常是不變的),最後放置變化最大的檔案(例如已編譯的應用程式)來優化Docker快取的使用。這將有利於現有層的使用，加快構建映象的速度，並間接加快映象掃描的速度。

10.掃描 Dockerfile 中的設定錯誤 

如我們所見，Docker映象構建過程遵循Dockerfile指令清單。

我們可以遵循以下幾種Dockerfile最佳實踐來檢測常見的安全性錯誤設定:

• 以特權(root)使用者身份執行，會存取比所需更多的資源。
• 暴露不安全的埠，例如不應在容器上開啓ssh 22埠。
• 由於錯誤的"COPY"或"ADD"命令不小心嵌入了私人檔案。
• 不通過環境變數或安裝注入(泄露)secret或憑據。允許使用者將選項傳遞給Entrypoint和CMD是一個好習慣。
• 特定策略定義許多其他內容，例如被阻止的軟體包、允許的基本映象、是否已新增SUID檔案等。

在這樣的Dockerfile中:

FROM ubuntu:focal-20200423
USER root
RUN curl http://my.service/?auth=ABD54F0356FA0054
EXPOSE 80/tcp
EXPOSE 22/tcp
ENTRYPOINT ["/main"]

我們的映象掃描可以自動檢測到以下問題:

USER root

我們以root身份執行:

EXPOSE 22/tcp

在這裏，我們將暴露通常用於ssh的22埠，這是容器不應該包含的工具。另外， 我們還將公開90埠，但這個沒問題，這就像HTTP伺服器的通用埠一樣。

 

RUN curl http://my.service/auth=ABD54F0356FA005432D45D0056AF5400

此命令使用一個auth金鑰，任何人都可以使用它來給我們造成危險，因此我們應該改用某種變數。這樣的金鑰不僅可以在Dockerfile上，還可以在映象中存在的任何檔案中使用正則表達式進行檢測。作爲一項額外措施，我們還可以檢查已知可儲存憑證的檔名。

11.快速標記 Kubernetes Deployment 中的漏洞

通過掃描的映象並不是絕對安全的。如果在掃描後，我們部署了映象，但此時發現了一個新漏洞，雖然我們可以立即加強安全策略，但是那些已經執行的映象會怎麼樣？

生產中部署的易受攻擊映象的時間軸：

因此我們要連續掃描映象以達到以下目標:

• 檢測新漏洞並進行符合我們策略的更改。
• 向相應團隊報告這些發現，以便他們儘快修復映象。

 

當然，實施執行時掃描可以幫助我們減少這些漏洞的影響。以 CVE-2019-14287 爲例， 我們可以編寫一些 Falco 規則來檢測該漏洞是否已被利用，但爲每個漏洞編寫特定規則是一項耗時的工作，應將其作爲最後一道防線。因此，我們要連續掃描叢集中正在執行的映象。

安全工具會使用不同的策略進行存檔，最簡單的方法是每隔幾個小時重新掃描一次所有映象。理想情況下，我們希望在漏洞列表更新後立即重新掃描受影響的映象。不過某些工具能夠儲存映象元數據，無需完全重新掃描即可檢測新漏洞。

一旦在執行中的容器中發現漏洞，我們就應儘快修復。這裏的關鍵是有效的漏洞報告，這樣每個人都可以專注於有關的資訊。

實現此目標的一種方法是使用可查詢的漏洞數據庫，該數據庫讓 DevOps 安全團隊可以在其龐大的映象、程式包和 CVE 目錄中進行一些排序。他們將搜尋諸如 CVE age、是否有可用的修復程式、軟體版本等參數。最後，如果可以下載這些報告並與漏洞管理團隊、CISO 共用，那麼將非常有用。

讓我們用一個例子來說明，現在有一個查詢包含了以下內容：所有的漏洞在 prod 名稱空間，嚴重性爲高，CVE>30 天，修復可用。

藉助這種漏洞報告功能，團隊可以輕鬆地識別出他們可以實際修復的易受攻擊映象，並在漏洞被利用之前開始着手解決方案。

12.選擇基於 SaaS 的掃描解決方案

在本地解決方案上選擇基於 SaaS 的掃描服務有很多好處：

• 按需擴充套件資源:我們可以首先掃描幾個映象，然後隨着容器應用程式的擴充套件而增長，無需擔心後端數據管理。
• 快速實施:我們可以將掃描嵌入到CI/CD管道中，並在幾分鐘內啓動並執行，而本地應用程式則需要更多時間來安裝和設定。
• 輕鬆升級和維護:SaaS提供商處理並推出修補程式程式不需要我們手動升級或更新新功能。
• 無需基礎設施或人員成本:我們可以避免爲擁有永久所有權的內容硬體和軟體許可證付費，也不需要現場維護和支援應用程式。

 

結論

映象掃描是DevSecOps工作流程中的第一道防線。通過使其自動化，我們可以最大程度地發揮其潛力，並在問題有機會變大之前發現問題。遵循映象掃描最佳實踐將幫助大家將安全性嵌入其中，並且交付速度不會因此降低。

最後，要記住映象掃描不該僅用一次，而要在工作流程中連續檢查，包括在構建時、在註冊表上、在部署之前以及容器已經執行時。

原文鏈接:https://sysdig.com/blog/image-scanning-best-practices/