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

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

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

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

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

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

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

挑戰(zhàn)

一、容器鏡像的問題

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

要避免的一些已知案例

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

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

建議

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

2.注意您的編排安全

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

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

當(dāng) Kubernetes 處理多個(gè)容器時(shí)，它在某種程度上暴露了一個(gè)很大的攻擊面。當(dāng)我們沒有保護(hù)編排器的生態(tài)系統(tǒng)時(shí)，遵循全行業(yè)實(shí)踐的字段級(jí)令牌化是不夠的。因?yàn)槊舾行畔⒈唤獯a和暴露只是時(shí)間問題。

建議

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

3. 防止“docker逃逸”

流行的容器運(yùn)行時(shí)，如 containerd、CRI-O 和 rkt 可能已經(jīng)隨著時(shí)間的推移強(qiáng)化了它們的安全策略，但是，它們?nèi)匀挥锌赡馨e(cuò)誤。這是一個(gè)需要考慮的重要方面，因?yàn)樗鼈兛梢栽试S惡作劇代碼在“容器逃逸”中運(yùn)行到主機(jī)上。

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

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

安全需要左移

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

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

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

總結(jié)

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