2010年下半年，人們對(duì)容器和容器平臺(tái)的興趣呈爆炸式增長(zhǎng)。在這股熱潮中，容器已成為排在 Linux和Windows虛擬機(jī)（VM）之后的第三大托管應(yīng)用程序的運(yùn)行時(shí)。

在本指南中，我們將探討在云端運(yùn)行容器的好處，并仔細(xì)探討如何確保容器化工作負(fù)載的安全性。

如何在云端運(yùn)行容器

與傳統(tǒng)應(yīng)用程序相比，容器鏡像不僅包含應(yīng)用程序，還包含了所有依賴(lài)項(xiàng)，包括系統(tǒng)庫(kù)、驅(qū)動(dòng)程序和配置。容器鏡像簡(jiǎn)化了部署，讓虛擬機(jī)上手動(dòng)配置操作系統(tǒng)和容易出錯(cuò)的設(shè)備安裝變成過(guò)去式。部署變得流暢、快速、無(wú)故障。

所有大型云服務(wù)提供商（CSP）都為運(yùn)行容器工作負(fù)載提供了多種云服務(wù)。第一種方式是客戶(hù)部署自己選擇的開(kāi)源或第三方容器平臺(tái)（如RedHat OpenShift或Apache Mesos）。他們自己在云端的虛擬機(jī)上安裝這些平臺(tái)。因此，在這種情況下，云提供商不參與容器平臺(tái)的安裝和運(yùn)行。

第二種選擇是在CSP提供的托管容器平臺(tái)服務(wù)上運(yùn)行容器。例如，Azure Kubernetes Service（AKS）、Google Kubernetes Engine（GKE）和Amazon Elastic Kubernetes Service。只需點(diǎn)擊一下，Kubernetes集群就會(huì)自動(dòng)啟動(dòng)。

在這種模式下，容器和平臺(tái)配置由客戶(hù)負(fù)責(zé)，這是這種模式與第三種選擇（云端集中容器運(yùn)行時(shí)平臺(tái)，如Azure Function Apps或Azure Web Apps）的主要區(qū)別。除了其他選項(xiàng)外，后一種服務(wù)還讓工程師能提供容器化應(yīng)用程序，并隱藏底層容器平臺(tái)的存在。因此，安全架構(gòu)師面臨的挑戰(zhàn)是如何確保這一大堆運(yùn)行容器化應(yīng)用程序的平臺(tái)的安全。

容器安全要求

為了有效地保護(hù)容器工作負(fù)載，安全架構(gòu)師需要全面了解技術(shù)層和安全相關(guān)任務(wù)。這些任務(wù)旨在加固所有相關(guān)組件、管理漏洞以及主動(dòng)識(shí)別和應(yīng)對(duì)整個(gè)技術(shù)棧的威脅和攻擊。

加固需要安全地配置所有組件，特別是采用強(qiáng)大的訪問(wèn)控制和網(wǎng)絡(luò)設(shè)計(jì)。漏洞管理應(yīng)識(shí)別自主開(kāi)發(fā)和第三方組件中的安全漏洞和錯(cuò)誤配置，并對(duì)其進(jìn)行修補(bǔ)。即使容器鏡像在部署時(shí)沒(méi)有漏洞，也可能在之后發(fā)現(xiàn)漏洞，Log4j就是一個(gè)例子。最后，黑客可以攻擊容器化應(yīng)用程序和底層容器平臺(tái)。因此，企業(yè)必須監(jiān)測(cè)容器資產(chǎn)中的異常情況和可疑行為（威脅檢測(cè)）。

加固、漏洞管理和威脅檢測(cè)對(duì)整個(gè)技術(shù)堆棧（圖 3，左）都是必需的，包括：底層基礎(chǔ)架構(gòu)層（虛擬機(jī)、網(wǎng)絡(luò)、存儲(chǔ)或云租戶(hù)設(shè)置）、容器平臺(tái)本身（如 OpenShift 或Amazon Elastic Kubernetes Service EKS），最后是每個(gè)容器化應(yīng)用。

平臺(tái)層的職責(zé)因云服務(wù)而異。對(duì)于Azure App Functions等容器化運(yùn)行時(shí)環(huán)境，客戶(hù)必須確保鏡像無(wú)漏洞，服務(wù)配置安全；其他一切均由CSP負(fù)責(zé)。相比之下，使用Amazon EKS集群則意味著容器平臺(tái)配置也是客戶(hù)的責(zé)任，不過(guò)CSP會(huì)為平臺(tái)組件打補(bǔ)丁。

圖4顯示了與容器工作負(fù)載相關(guān)的所有安全挑戰(zhàn)。如果客戶(hù)而不是CSP負(fù)責(zé)特定層的話(huà)，安全架構(gòu)師就必須了解并確定如何處理運(yùn)行容器鏡像的每個(gè)云服務(wù)（如 Azure Function App、Amazon EKS、Cloud Run）的每一個(gè)技術(shù)堆棧層（應(yīng)用、平臺(tái)、基礎(chǔ)設(shè)施）的安全任務(wù)（加固、漏洞管理、攻擊/威脅檢測(cè)）。

為容器化工作負(fù)載提供安全保障

微軟Defender或谷歌的安全中心等云原生安全工具是保護(hù)公共云中容器化工作負(fù)載安全的首選解決方案。這些工具可以檢測(cè)容器工作負(fù)載和底層平臺(tái)中的漏洞和威脅。雖然它們肯定不是免費(fèi)的，但是客戶(hù)只要點(diǎn)擊一兩下（或者很少幾下）就可以激活，并且立竿見(jiàn)影地提高安全性。

Azure Function Apps是可以運(yùn)行容器化工作負(fù)載的Azure 服務(wù)之一，在研究Azure Function Apps 時(shí)，微軟的Defender for Cloud是最合適的產(chǎn)品。首先，它提供Defender Recommendations，這些建議列出了不安全的參數(shù)和配置選擇，如“應(yīng)該只能通過(guò)HTTPS 訪問(wèn)Function App”。這些建議（部分）基于CIS基準(zhǔn)。Defender的第二大功能Attack Paths分析著眼于更廣泛的環(huán)境。它能夠識(shí)別利用多種非完美配置選擇入侵公司云資產(chǎn)的攻擊路徑(2)。最后，Defender Security Alerts會(huì)就正在進(jìn)行的、可能是攻擊的活動(dòng)向?qū)＜野l(fā)出報(bào)警（3）.

微軟Defender之于Azure就像是Amazon GuardDuty之于 AWS或者Google Security Command Center之于GCP：很棒的開(kāi)箱即用云原生服務(wù)，可確保（不限于）基于容器的工作負(fù)載的安全。除了這些云原生解決方案，第三方安全工具也是可行的選擇。規(guī)模較大的企業(yè)應(yīng)該對(duì)它們和云原生服務(wù)的功能和成本進(jìn)行比較。

當(dāng)首席信息安全官們要求全面覆蓋所有基于云的容器工作負(fù)載時(shí)，容器安全的真正挑戰(zhàn)就開(kāi)始了。這時(shí)，安全架構(gòu)師需要分別分析每個(gè)相關(guān)的云服務(wù)。在分析過(guò)程中，他們應(yīng)特別關(guān)注三個(gè)問(wèn)題：

• 加固是根據(jù)公司具體的工作負(fù)載和云設(shè)置來(lái)定義粒度規(guī)則。什么時(shí)候可以接受虛擬機(jī)公開(kāi)暴露？API調(diào)用何時(shí)需要（或者必須不要）身份驗(yàn)證？這是一個(gè)更為全面的目標(biāo)，不僅僅是確保不存在明顯的漏洞。
• 針對(duì)容器或容器鏡像的漏洞掃描有兩種模式：存儲(chǔ)庫(kù)掃描和運(yùn)行時(shí)掃描。后者只檢查有風(fēng)險(xiǎn)的、正在使用的鏡像，這樣做的好處是：不會(huì)因?yàn)橐褎?chuàng)建但未部署的鏡像給出誤報(bào)。不過(guò)，并非所有服務(wù)都有運(yùn)行時(shí)掃描。后備方案是掃描GCP Artifact Registry等存儲(chǔ)庫(kù)中等鏡像，這種方式還允許將漏洞掃描集成到CI/CD管道中。
• 威脅檢測(cè)需要分析容器中的活動(dòng)和底層平臺(tái)中的可疑行為和異常。與基于容器的漏洞掃描類(lèi)似，安全架構(gòu)師可能需要仔細(xì)檢查所有基于容器的環(huán)境是否都有這種功能（并處于激活狀態(tài)）。

此外，第三方容器安全解決方案當(dāng)然也是可行的選擇。不過(guò)，至少對(duì)于大型企業(yè)來(lái)說(shuō)，必須將它們的功能和成本與云原生解決方案進(jìn)行比較。

遏制威脅

對(duì)于 首席信息安全官們來(lái)說(shuō)，容器安全的可怕現(xiàn)實(shí)是，容器技術(shù)已經(jīng)滲透到大多數(shù) IT 組織中。雖然首席信息安全官和首席信息官們通常都了解手頭的大型Kubernetes集群，但他們不太了解很多不那么起眼但也使用容器的云服務(wù)。由于黑客的目標(biāo)是找到未受保護(hù)的服務(wù)（而不是攻擊受保護(hù)的服務(wù)），因此企業(yè)必須分析容器工作負(fù)載的位置，并確保所有容器的安全。