一種經(jīng)濟高效且不太復(fù)雜的虛擬機（容器）替代方案徹底改變了應(yīng)用程序交付方法。它們顯著減少了管理應(yīng)用程序基礎(chǔ)設(shè)施的 IT 勞動力和資源。然而，在保護容器和容器化生態(tài)系統(tǒng)的同時，軟件團隊遇到了許多障礙。特別是對于習(xí)慣于更傳統(tǒng)的網(wǎng)絡(luò)安全流程和策略的企業(yè)團隊。我們通常鼓吹容器提供更好的安全性，因為它們將應(yīng)用程序與主機系統(tǒng)以及彼此隔離開來。在某些地方，我們讓它聽起來像是天生安全，幾乎無法抵御威脅。但這個想法有多牽強呢？讓我們直接進入它。

讓我們對市場的情況有一個高層次的了解。據(jù)美國商業(yè)資訊報道，到 2027 年，全球容器安全市場規(guī)模預(yù)計將達到 39 億美元，復(fù)合年增長率為 23.5%。

與任何軟件非常相似，容器化應(yīng)用程序可能會成為安全漏洞的犧牲品，包括錯誤、身份驗證和授權(quán)不充分以及配置錯誤。

讓我們了解下面的容器威脅模型：

容器中可能存在的脆弱因素

• 外部攻擊者（來自外部）試圖訪問我們的部署之一（特斯拉被加密黑客攻擊）。
• 對生產(chǎn)環(huán)境具有一定訪問權(quán)限的內(nèi)部攻擊者（不一定是管理員）。
• 惡意內(nèi)部因素是有權(quán)訪問部署的開發(fā)人員和管理員等特權(quán)內(nèi)部用戶。
• 無意的內(nèi)部因素可能會意外導(dǎo)致問題，例如在容器鏡像中不小心存儲了一些密鑰或證書。
• 通過引入一些新服務(wù)或減少等待時間來增強客戶體驗，公司往往會在其服務(wù)器或防火墻中打開一些端口。如果不嚴防死守，這里很可能成為黑客的通道。

可能有多種途徑會損害您的容器安全性（上圖對此進行了大致總結(jié)）。讓我們準確地討論其中的一些因素。

挑戰(zhàn)

一、容器鏡像的問題

不僅僅是擁有惡意軟件。配置不當?shù)娜萜麋R像可能是引入漏洞的原因。當人們認為他們可以旋轉(zhuǎn)自己的圖像或從云端下載并直接開始使用時，問題就開始了。我們應(yīng)該知道，每天都會在云上引入新的漏洞。每個容器鏡像都需要單獨掃描以證明它是安全的。

要避免的一些已知案例

• 如果映像啟動允許未經(jīng)授權(quán)的網(wǎng)絡(luò)訪問的無關(guān)守護程序或服務(wù)怎么辦？
• 如果它被配置為使用比必要更多的用戶權(quán)限怎么辦？
• 另一個需要注意的危險是鏡像中是否存儲了任何密鑰或憑證。

注意：從以上所有案例中，我們注意到 Docker 始終會將其自己的網(wǎng)絡(luò)優(yōu)先于您的本地網(wǎng)絡(luò)。

建議

• 從受信任的容器注冊表中拉取圖像。受信任的容器注冊表配置不當。通常指的是私有注冊中心，但不一定，除非它們是加密的并且具有經(jīng)過身份驗證的連接。這應(yīng)該包括與現(xiàn)有網(wǎng)絡(luò)安全控制聯(lián)合的憑據(jù)。
• 容器注冊表應(yīng)進行頻繁的維護測試，以使其不存在任何具有揮之不去的漏洞的陳舊圖像。
• 在將它們投入生產(chǎn)之前，軟件團隊需要通過藍綠部署或容器更改的回滾來構(gòu)建共享實踐。

2.注意您的編排安全

在解決安全問題時，像 Kubernetes 這樣流行的編排工具是不可或缺的。它已成為主要的攻擊面。

據(jù)Salt Security稱，大約 34% 的組織完全沒有適當?shù)?API 安全策略。除此之外，27% 的受訪者表示他們只有一個基本策略，包括對 API 安全狀態(tài)進行最少的掃描和手動審查，并且沒有對其進行控制。

當 Kubernetes 處理多個容器時，它在某種程度上暴露了一個很大的攻擊面。當我們沒有保護編排器的生態(tài)系統(tǒng)時，遵循全行業(yè)實踐的字段級令牌化是不夠的。因為敏感信息被解碼和暴露只是時間問題。

建議

• 確保 orchestrator 的管理界面被正確加密，這可以包括雙因素身份驗證和靜態(tài)數(shù)據(jù)加密。
• 將網(wǎng)絡(luò)流量分離到離散的虛擬網(wǎng)絡(luò)中。這種隔離應(yīng)該根據(jù)傳輸?shù)牧髁康拿舾行詠硗瓿伞＃ɡ纾嫦蚬姷?Web 應(yīng)用程序可以歸類為低敏感度工作負載，而像稅務(wù)報告軟件這樣的東西可以歸類為高敏感度工作負載并將它們分開。這個想法是確保每個主機運行特定安全級別的容器。）
• 最佳實踐可以是堅持對集群節(jié)點之間的所有網(wǎng)絡(luò)流量進行端到端加密，還包括集群成員之間經(jīng)過身份驗證的網(wǎng)絡(luò)連接。
• 我們的目標應(yīng)該是將節(jié)點安全地引入集群，在每個節(jié)點的整個生命周期中保持一個持久的身份。（在不影響集群安全的情況下隔離/移除受感染的節(jié)點）。

3. 防止“docker逃逸”

流行的容器運行時，如 containerd、CRI-O 和 rkt 可能已經(jīng)隨著時間的推移強化了它們的安全策略，但是，它們?nèi)匀挥锌赡馨e誤。這是一個需要考慮的重要方面，因為它們可以允許惡作劇代碼在“容器逃逸”中運行到主機上。

如果您還記得在 2019 年，在 runC 中發(fā)現(xiàn)了一個名為Runscape的漏洞。

這個錯誤 ( CVE-2019-5736) 有可能使黑客能夠脫離沙盒環(huán)境并授予對主機服務(wù)器的根訪問權(quán)限。這導(dǎo)致整個基礎(chǔ)設(shè)施受到損害。起初，他們假設(shè)它可能是一個惡意的 Docker 鏡像，因為里面肯定有一個惡意進程。經(jīng)過所有測試，他們意識到這是 runC 中的一個錯誤。

安全需要左移

在處理基于微服務(wù)的環(huán)境時，最佳實踐是在每一步都引入自動化部署。如果我們?nèi)匀话凑彰恐芑蛎吭碌墓?jié)奏手動執(zhí)行部署，那么我們就不是敏捷的。要在應(yīng)用程序交付中真正向左移動，我們需要創(chuàng)建一個現(xiàn)代的安全插件工具鏈及其在整個管道中的擴展。

它是這樣工作的：如果圖像中存在任何漏洞，該過程應(yīng)該在構(gòu)建階段就停止。應(yīng)該對 RBAC 進行定期審計以監(jiān)控所有訪問級別。此外，所有工具和流程都應(yīng)符合 CIS 基準。

一個好的方法是采用安全即代碼實踐，將 Kubernetes 原生 YAML 文件的安全清單編寫為自定義資源定義。這些是人類可讀的，并在運行時聲明應(yīng)用程序的安全狀態(tài)。現(xiàn)在，可以將其推送到生產(chǎn)環(huán)境中并使用零信任模型進行保護。因此，管道外的代碼永遠不會有任何更改。

總結(jié)

是時候總結(jié)一下容器化和容器安全處理了。我的目標是在實踐容器化時突出一些容易實現(xiàn)但被高度忽視的區(qū)域。如今，跨 CI/CD 管道的自動化安全流程和聲明式零信任安全策略已成為當務(wù)之急。它們提高了開發(fā)人員的工作效率，并且是 DevOps 最佳實踐的一部分。