2010年下半年，人們對容器和容器平臺的興趣呈爆炸式增長。在這股熱潮中，容器已成為排在 Linux和Windows虛擬機（VM）之后的第三大托管應用程序的運行時。

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

如何在云端運行容器

與傳統應用程序相比，容器鏡像不僅包含應用程序，還包含了所有依賴項，包括系統庫、驅動程序和配置。容器鏡像簡化了部署，讓虛擬機上手動配置操作系統和容易出錯的設備安裝變成過去式。部署變得流暢、快速、無故障。

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

第二種選擇是在CSP提供的托管容器平臺服務上運行容器。例如，Azure Kubernetes Service（AKS）、Google Kubernetes Engine（GKE）和Amazon Elastic Kubernetes Service。只需點擊一下，Kubernetes集群就會自動啟動。

在這種模式下，容器和平臺配置由客戶負責，這是這種模式與第三種選擇（云端集中容器運行時平臺，如Azure Function Apps或Azure Web Apps）的主要區別。除了其他選項外，后一種服務還讓工程師能提供容器化應用程序，并隱藏底層容器平臺的存在。因此，安全架構師面臨的挑戰是如何確保這一大堆運行容器化應用程序的平臺的安全。

容器安全要求

為了有效地保護容器工作負載，安全架構師需要全面了解技術層和安全相關任務。這些任務旨在加固所有相關組件、管理漏洞以及主動識別和應對整個技術棧的威脅和攻擊。

加固需要安全地配置所有組件，特別是采用強大的訪問控制和網絡設計。漏洞管理應識別自主開發和第三方組件中的安全漏洞和錯誤配置，并對其進行修補。即使容器鏡像在部署時沒有漏洞，也可能在之后發現漏洞，Log4j就是一個例子。最后，黑客可以攻擊容器化應用程序和底層容器平臺。因此，企業必須監測容器資產中的異常情況和可疑行為（威脅檢測）。

加固、漏洞管理和威脅檢測對整個技術堆棧（圖 3，左）都是必需的，包括：底層基礎架構層（虛擬機、網絡、存儲或云租戶設置）、容器平臺本身（如 OpenShift 或Amazon Elastic Kubernetes Service EKS），最后是每個容器化應用。

平臺層的職責因云服務而異。對于Azure App Functions等容器化運行時環境，客戶必須確保鏡像無漏洞，服務配置安全；其他一切均由CSP負責。相比之下，使用Amazon EKS集群則意味著容器平臺配置也是客戶的責任，不過CSP會為平臺組件打補丁。

圖4顯示了與容器工作負載相關的所有安全挑戰。如果客戶而不是CSP負責特定層的話，安全架構師就必須了解并確定如何處理運行容器鏡像的每個云服務（如 Azure Function App、Amazon EKS、Cloud Run）的每一個技術堆棧層（應用、平臺、基礎設施）的安全任務（加固、漏洞管理、攻擊/威脅檢測）。

為容器化工作負載提供安全保障

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

Azure Function Apps是可以運行容器化工作負載的Azure 服務之一，在研究Azure Function Apps 時，微軟的Defender for Cloud是最合適的產品。首先，它提供Defender Recommendations，這些建議列出了不安全的參數和配置選擇，如“應該只能通過HTTPS 訪問Function App”。這些建議（部分）基于CIS基準。Defender的第二大功能Attack Paths分析著眼于更廣泛的環境。它能夠識別利用多種非完美配置選擇入侵公司云資產的攻擊路徑(2)。最后，Defender Security Alerts會就正在進行的、可能是攻擊的活動向專家發出報警（3）.

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

當首席信息安全官們要求全面覆蓋所有基于云的容器工作負載時，容器安全的真正挑戰就開始了。這時，安全架構師需要分別分析每個相關的云服務。在分析過程中，他們應特別關注三個問題：

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

此外，第三方容器安全解決方案當然也是可行的選擇。不過，至少對于大型企業來說，必須將它們的功能和成本與云原生解決方案進行比較。

遏制威脅

對于 首席信息安全官們來說，容器安全的可怕現實是，容器技術已經滲透到大多數 IT 組織中。雖然首席信息安全官和首席信息官們通常都了解手頭的大型Kubernetes集群，但他們不太了解很多不那么起眼但也使用容器的云服務。由于黑客的目標是找到未受保護的服務（而不是攻擊受保護的服務），因此企業必須分析容器工作負載的位置，并確保所有容器的安全。