容器正在迅速成為云原生生態系統中計算和工作負載部署的實際形式。
云原生計算基金會(CNCF)最近發布的云原生報道顯示：96%的組織不是在積極地使用容器和Kubernetes，就是在對容器和Kubernetes進行評估。容器的優點是眾所周知的，比如可移植性、一致性和高效性。但同時，容器也隱含著一些安全問題。
容器安全是一個復雜的事情，它類似于是網絡安全的一個拓展。容器安全要求人員、流程以及技術的結合，其中人員是最重要的部分。因此，那些期望廣泛應用容器的組織應該幫助現有的職工提高技術水平，并引進一些具有必要技能的新員工，從而確保一個安全的云原生操作模式。其中，容器是該模式的關鍵組成部分。
目前，最大的政府機構和技術方面的權威對軟件供應鏈安全的關注正不斷升溫，這需要達到一定的嚴格度和成熟度，然而大多數組織都達不到該水平。在密切關注行業最佳實踐和指導的基礎上，通過實施下述的實踐和工具，我們就可以更加接近安全容器使用預期的最終狀態。
容器，云安全中相互交織的部分
首先，了解容器在云環境中的角色以及容器之間的交互是非常重要的。云原生生態系統通常具有云安全的四個C：云(cloud)、集群(cluster)、容器(container)以及代碼(code)。云的脆弱性、Kubernetes集群以及應用程序，其本身就具有一些安全問題，但這些超出了這里所要討論的范圍。
容器安全并非微不足道的小事。特別是由于容器存在的狀態，例如映像或者運行時的容器，以及容器中的層和代碼。CNCF發布的白皮書《Cloud-NativeSecurity》在推動更好地了解云原生應用、容器及其生命周期方面，起了個好頭。
注意容器可移植性的危險
容器的可移植性是它最為顯著的優點之一。但這既是優點，也是缺陷。由于容器通常是在多租戶架構上運行的，所以如果向一個容器中引入脆弱性，然后進行分發，那么實際上就是把該脆弱性發送給了使用該映像的所有人。并且還可能將它運行的環境置于風險之中。這意味著容器映像的可移植性以及分布式等特性可以被廣泛地利用和共享。這使得容器與其他問題聯系在一起，例如：開源代碼、基礎設施即代碼(laC)。這些都是本身就帶有脆弱性的。
容器通常是由外部的開發人員構建，然后分發給企業的。這意味著諸如安全編碼實踐和容器安全最佳實踐等是一個很好的起點，但后者意味著什么呢?
在容器投入生產之前，對其進行掃描以檢測脆弱性
已經出現的一些基本的最佳實踐包括：通過掃描(CI/CD)管道中的容器來防止脆弱性被引入到運行時的生產環境。Anchore和Trivvy等開源代碼，以及Snyk等行業領導者都是很好的選擇。
在管道部署活動期間掃描容器，更為廣泛地推動了安全的左移。在管道中捕捉容器的脆弱性，可以防止脆弱性被引入到生產環境中，同時也可以預防不法分子趁虛而入。這比直接在生產環境中修補脆弱性，更加的高效，同時也降低了風險和成本。
因為許多容器是開發人員用來部署應用而創建的，所以這些工具可以幫助他們解決問題。這比創建一個可能會人手不夠，且負擔過重的安全團隊來進行反復溝通，更加的有效。從而也避免了價值交付瓶頸期的產生。
盡管如此，在管道中掃描容器映像并不是一個萬全之策。容器映像通常情況下被存儲在存儲庫中，一旦部署到生產環境，就將以運行狀態存在。所以關鍵點是：在兩種環境中都要掃描它們。新漏洞是不斷出現的。因此，簡單地從存儲庫中提取以前掃描過的映像，并在不進行新掃描的情況下部署它，就可能會忽略掉一些自上次掃描以來發現的新漏洞。
同樣的道理也適用于生產運行中的脆弱性。由于潛在的訪問控制不良情況的發生，運行狀態下的的容器可能已經遭到了篡改。我們可以通過識別運行時容器中的脆弱性，并利用工具通知相關工作人員來進行相應的調查以及潛在的干預。
使用容器映像簽名
映像簽名是保護容器工作負載的另一個關鍵活動。我們都知道：網絡安全的CIA三要素：保密性、完整性以及可用性。容器映像簽名就類似于一種確保容器映像完整性的工具。它能夠確保你正在使用的容器映像是沒有被篡改，并且可信任的。這部分的操作可以集成到DevOps工作流中，也可以在注冊表中完成。
對于容器映像簽名，有若干選項可供選擇。最值得關注的其中一個是Cosign，它支持映像簽名以及驗證和存儲。同時，它還支持一些其他選項，比如硬件、密鑰管理服務(KMS)、以及自帶的公鑰基礎設施等。
另一方面，無鑰簽名正逐漸嶄露頭角，并且受到了像Chainguard等創新團隊的支持。無鑰簽名的本質是支持“短期”密鑰，這種“短期”密鑰與身份綁定，并且僅在進行簽名活動的這段時間內存在。
為容器映像構建軟件物料清單
即使是容器，同樣也無法避免軟件供應鏈中的一些安全問題的。企業正在設法利用工具來為其容器映像生成軟件物料清單(SBOMs)。其中最著名的一個例子是Anchore的Syft工具。Syft可以為容器映像創建SBOM，并把此部分操作集成到CI/CD工作流程中。同時，Syft還可以使企業對其在容器生態環境中運行的軟件有更深入的了解，并在其他Log4類型場景發生時更好地做出響應。
這種程度的可視化在傳統上是難以捉摸的。但在白宮和相關聯邦機構(如網絡安全行政令EO)命令的指導下，各組織開始越來越關注軟件供應鏈安全。NIST等組織發布了更新的安全軟件開發框架(SSDF)，該架構要求將SBOM應用到歸檔和軟件發布保護等活動中。隨著SSDF的發布，對于安全開發實踐的關注度將會越來越高。
基于容器映像的SBOM需求是在推動認證的發展。這一點是TestifySec以及NIST在其軟件供應鏈安全指南中所倡導的。NIST要求對SSDF進行認證，而SSDF則要求使用SBOM。還有一些創新的選項可以進一步加強SBOM，例如Syft，它可以支持in-toto規范的SBOM認證。這種認證方式幫助簽名者證明：SBOM正是容器映像內容的準確表示。
點評
容器因其可移植性、簡單的可擴展性以及較低的管理負擔等優點，被越來越廣泛地應用于應用軟件的部署當中。但是，容器既不提供不可滲透的安全邊界，也并不以此為目標。容器所帶來的安全隱患同樣應受到相應的關注與重視。
