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

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

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

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

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

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

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

挑戰(zhàn)

一、容器鏡像的問題

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

要避免的一些已知案例

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

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

建議

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

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)絡流量分離到離散的虛擬網(wǎng)絡中。這種隔離應該根據(jù)傳輸?shù)牧髁康拿舾行詠硗瓿伞＃ɡ纾嫦蚬姷?Web 應用程序可以歸類為低敏感度工作負載，而像稅務報告軟件這樣的東西可以歸類為高敏感度工作負載并將它們分開。這個想法是確保每個主機運行特定安全級別的容器。）
• 最佳實踐可以是堅持對集群節(jié)點之間的所有網(wǎng)絡流量進行端到端加密，還包括集群成員之間經(jīng)過身份驗證的網(wǎ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)境并授予對主機服務器的根訪問權限。這導致整個基礎設施受到損害。起初，他們假設它可能是一個惡意的 Docker 鏡像，因為里面肯定有一個惡意進程。經(jīng)過所有測試，他們意識到這是 runC 中的一個錯誤。

安全需要左移

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

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

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

總結

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