本文探討可縮小容器映像大小的 Distroless 技巧以及這項技巧如何解決資安疑慮。此外也提出另一種替代 Distroless 的方法，既能縮小雲端原生應用程式受攻擊面以防範駭客攻擊，又能讓雲端資源最佳化。

自從  2013 年誕生以來，Docker 已徹底改變了開發人員使用容器的方式。而 Docker Hub 的出現，也成了開發人員分享容器映像的主要管道。為了不重新發明輪子，大多數開發人員在使用容器來部署應用程式時都會以 Docker Hub 提供的公開映像作為基礎。某些 Docker Hub 上最熱門的映像 (例如官方提供的機碼/數值儲存伺服器映像) 就是以 Debian 的官方映像作基礎。儘管這樣的作法看似不錯，但開發人員通常不會為了雲端資安而仔細檢查每一個映像的內容。

官方映像通常是由某個開發社群負責維護，雖然開發人員也會使用基本作業系統 (OS) 映像，但絕大多數應用程式映像都是建立在其他映像之上。這意味著，基礎映像所包含的任何漏洞和資安弱點，也會跟延續到應用程式映像當中。

本文詳細探討「Distroless」這個可提升容器映像資安 (以及其他好處) 的技巧，以及另一個可縮小容器映像大小和受攻擊面以避免雲端原生應用程式遭駭客攻擊的替代方案。

業界當前的作法

最近， 軟體成分清單 (SBOM) 突然成為資安界的一項熱門話題，SBOM 是一份有關某個容器或檔案系統內所有已安裝套件的清單，而 Syft 則是目前業界用來產生 SBOM 的標準工具。

我們使用 Syft 產生了一份 Debian 官方公開映像的套件清單：

如圖 1 所示，這個映像當中含有 96 個套件。此外，我們還可以用 Grype (同樣也是一個日漸受到關注的工具) 來分析 Syft 所產生的 SBOM，它可掃描映像當中是否存在著漏洞。

使用 Debian 基礎映像的風險顯而易見：其內含的套件越多，受攻擊面就越大，此外也會占用更多磁碟空間與頻寬，這就是為何許多開發人員都捨棄 Debian 基礎映像而改用以 Alpine 建立的映像。對於新手來說，Alpine Linux 是一個以資安為導向的輕量化 Linux 發行版本，採用 musl libc 與 BusyBox 為基礎。

從下圖就能看出 Alpine Linux 的優勢：

就目前來說，其含有的漏洞數量為零。

Alpine Linux 更優異的安全性確實是大好消息，而且 Alpine Linux 還會適時發布更新。

當前問題

如果您以為容器映像中的程式碼漏洞都來自於原始基礎映像，那就太簡化問題了，開發人員所撰寫的應用程式也會為容器帶來潛在漏洞。為了方便看到問題，我們暫時假設任何容器都可能執行到一個含有遠端程式碼執行 (RCE) 漏洞的應用程式。

假使開發人員使用的是 Debian 基礎容器映像，然後裡面包含了駭客可利用的「apt」套件管理員程式，駭客便有機可乘。Alpine 基礎官方映像也是如此，因為它裡面也有一個名為「apk」的套件管理員程式，以及將許多 UNIX 常用小工具 (如 wget) 整合成單一執行檔的 BusyBox。

駭客隨時都在尋找可利用的漏洞，因此我們要盡可能消除駭客的機會，不讓駭客的攻擊進入到下一階段。

從駭客的角度來看，如果他要攻擊暴露在外的容器並取得指令列介面的控制權，那麼套件管理員是他們必須克服的障礙。但這並非我們在發掘受攻擊面時唯一需要擔心的問題。還有許多 Linux 內建工具 (視採用的基礎映像而定) 可能被用於惡意用途，所以最好將這些工具從映像當中徹底移除。

一個解決方法就是詳細列出這所有工具，然後在建構映像時將其執行檔排除。不過，這樣的作法有兩個問題：其一是要列出這所有工具相當麻煩，其二是駭客還是會想盡辦法利用剩餘的工具。

「base64」就是一個很好的例子，這個工具存在於所有的容器基礎映像以及完整版的 Linux 發行版本。這是一個用來將資料編碼及解碼以方便傳輸的工具。我們發現專門攻擊雲端原生容器的駭客經常使用這個工具來解開他們下載的各種 base64 編碼檔案，因為他們知道目標系統一定有這個工具可用來解開檔案，以便進行後續攻擊。

另一個值得注意的問題是，許多雲端服務供應商 (CSP) 的服務也是在容器或微虛擬機器 (VM) 內執行，而它們使用的映像除了必要的套件之外，還安裝了其他套件。

當一個容器暴露在外，而其執行的應用程式遭到入侵，駭客就能使用容器內的工具來進行下一階段的攻擊，不論應用程式是在企業內或雲端內執行。

如何解決這項資安問題？

顯然，我們必須縮小受攻擊面。Google 提出了一種名為「Distroless 」的容器映像，這些映像只包含應用程式本身以及應用程式執行時所需要的元件。有別於標準的 Linux 發行版本，Distroless 容器內並無套件管理員、指令列介面或其他程式。

圖 8 和 9 所顯示的 Amazon Web Service (AWS) 映像並不一定是他們服務所使用的映像，但卻是 AWS 提供給使用者打造其他映像的基礎映像。

以上方法可讓我們解決目前看到的兩大資安問題：首先，我們能大幅減少映像包含的套件數量，只保留應用程式執行時所必要的套件。這麼做可以縮小受攻擊面，減少駭客可利用的機會。其次，可大幅減少漏洞的數量，在大多數情況下甚至可降至零。如此一來，應用程式在部署時就更加安全。

Distroless 的替代方案

當我們在開始研究這項問題時，我們發現 Distroless 的作法是盡可能讓容器變得更輕量化、也更快。但許多時候，我們發現容器映像其實並無任何非必要工具或函式庫，有些甚至使用了 空白映像 (scratch image)， 只包含幾個基礎檔案系統，其他的必須在後面掛載。

所以，我們想在此提出一個 Distroless 的替代方案，那就是採用多階段的建構方法並搭配一個空白映像，裡面只包含應用程式執行時所必要的函式庫。

這樣的作法非常適合無伺服器 (serverless) 功能，因為無伺服器功能的核心概念就是將應用程式拆解成多個較小的功能，透過這些無伺服器功能來處理資料。換句話說，每個功能都是只為單一目的而生。雖然這是原本的目的，但在真實世界裡，使用者不一定這麼應用。

若使用容器映像來建構，要讓功能可以執行，容器必須包含兩項元素：其一是程式語言解譯器，其二是 CSP 應用程式開發介面 (API) 的執行檔。根據我們的測試結果顯示，我們不僅可大幅縮小容器大小，更可降低 CSP 容器映像的受攻擊面與漏洞數量。

結論

Distroless 容器映像概念的出現已有好一段時間，但目前仍未成為主流。隨著容器資安相關研究逐漸累積，我們將繼續發揮我們的專業能力來研究容器資安對雲端基礎架構的影響。我們的研究已證明了 Distroless 容器映像的發展潛力，以及它如何讓資源最佳化，並解決資安疑慮。不過，有鑑於 Distroless 的一些缺點，我們也提出了另一種替代方案，那就是使用多重階段建構方式，從空白映像開始，裡面僅包含應用程式執行所必要的函式庫。只要實作得當，這樣的方法既可解決漏洞管理的問題，又可縮小受攻擊面，降低雲端原生應用程式遭駭客攻擊的機會。  

這種使用空白映像的多重階段建構方法，具備以下優點可幫助開發人員改善雲端資安：

• 適合無伺服器 (serverless) 功能，因為無伺服器功能的核心概念就是將應用程式拆解成多個較小的功能，透過這些無伺服器功能來處理資料。
• 不僅可大幅縮小容器大小，更可降低 CSP 容器映像的受攻擊面與漏洞數量。

◉原文出處：Enhancing Cloud Security by Reducing Container Images Through Distroless Techniques 作者：Alfredo Oliveira 與 Raphael Bottino