容器憑藉其經濟高效的優勢改變了應用程式的交付方式，隨著容器的普遍使用，管理應用程式基礎設施的 IT 勞動力和資源也顯著減少。然而，在保護容器和容器化生態系統時，軟體團隊遇到了許多障礙。尤其是習慣於更傳統的網路安全流程和策略的企業團隊。從理論上來說，容器看起來似乎能夠提供更好的安全性，因為容器將應用程式與主機系統彼此隔離開來。但實際真的如此嗎？
讓我們來看一組市場資料。據美國商業資訊報導，到 2027 年，全球容器安全市場規模預計將達到 39 億美元，複合年增長率為 23.5%。顯而易見，市場對於容器安全的需求將越來越大。與任何軟體一樣，容器化應用程式也可能受到安全漏洞影響，包括錯誤、身份驗證和授權不充分以及配置錯誤，因此容器安全問題不容忽視。
容器中的安全威脅
容器中可能存在的安全威脅有：
-
外部攻擊者試圖訪問企業部署。
-
對生產環境具有一定訪問許可權的內部攻擊者（不一定是管理員）。
-
有權訪問部署的開發人員和管理員等特權內部使用者的有意破壞。
-
無意的內部因素可能會意外導致問題，例如在容器映象中不小心儲存了一些金鑰或證書。
-
透過引入一些新服務或減少等待時間來增強客戶體驗，公司往往會在其伺服器或防火牆中開啟一些埠。如果不嚴防死守，這些埠很可能成為駭客的通道。
圖片來源：Container Security by Liz Rice
上述多種途徑會損害企業的容器安全性。接下來我們將一起來討論容器安全面臨的挑戰以及應對建議。
容器安全面臨的挑戰
1. 容器映象問題
引入漏洞將會導致配置不當的容器映象。事實上每天雲端都會引入不同的新漏洞。如果使用者直接從雲上獲取映象並直接開始使用，就會存在一定安全風險。所以每個容器映象在使用之前都需要進行單獨掃描從而保證其安全性。
常見的一些問題案例：
-
映象啟動允許未經授權的網路訪問的無關程式或服務
-
容器映象被配置超出使用者使用的普通許可權（配置的許可權大於使用者使用）
-
映象中儲存了金鑰或憑證
建議：
-
從受信任的容器映象倉庫中拉取影像，因為這類的映象倉庫通常擁有良好的配置，通常指的是私有映象倉庫，經過加密並且需要經過身份驗證。
-
容器映象倉庫應進行定期頻繁的維護測試，以此來減少和消除包含漏洞的映象。
-
在將映象投入生產之前，軟體團隊需要透過藍綠部署（Blue-Green deployments）或容器更改的回滾來構建共享實踐。
2. 編排安全問題
在解決容器安全問題時，像 Kubernetes （K8s）這樣的編排工具是不可或缺的。目前 K8s 已成為主要的攻擊面。據 Salt Security 稱，大約 34% 的組織完全沒有適當的 API 安全策略。除此之外，27% 的受訪者表示他們只有一個基本策略，包括對 API 安全狀態進行最少的掃描和手動審查，並且沒有對其進行控制。
當 K8s 處理多個容器時，在某種程度上暴露了很大的攻擊面。當沒有保護編排器的生態系統時，僅僅遵循全行業實踐的欄位級令牌化是不夠的。因為敏感資訊被解碼和暴露只是時間問題。
建議：
- 確保 orchestrator 的管理介面被正確加密，包括雙因素身份驗證和靜態資料加密。
- 將網路流量分散隔離，隔離則需要根據傳輸的流量的敏感性來管理。例如，面向公眾的 Web 應用程式可以歸類為低敏感度工作負載，而像稅務報告軟體等可以歸類為高敏感度工作負載並將它們隔離。這個想法是確保每個主機執行特定安全級別的容器。
- 對叢集節點之間的所有網路流量進行端到端加密，其中還包括叢集成員之間經過身份驗證的網路連線。
- 將節點安全地引入叢集，在不影響叢集安全的情況下隔離/移除受感染的節點。
3. 防止“容器逃逸”問題
使用較多的容器執行時例如 containerd、CRI-O 和 rkt，可能已經隨著時間的推移強化了它們的安全策略，但是，它們仍然無法避免漏洞問題。這是一個嚴重的安全問題，因為這些容器執行時允許惡意程式碼在“container escape”中執行到主機上。
在 2019 年，runC 中發現了一個名為 Runscape 的漏洞。這個漏洞 ( CVE-2019-5736) 能夠讓駭客能夠脫離沙盒環境並授予對主機伺服器的根訪問許可權，從而導致整個基礎設施受到損害。起初，人們只是假設這可能是一個惡意的 Docker 映象，但經過一系列測試後才意識到這是 runC 中的一個危險漏洞。
安全左移
在處理基於微服務的環境時，建議在每一步都引入自動化部署。如果仍然按照每週或每月這樣的頻率來手動執行部署，整個過程就無法達到敏捷狀態。要在應用程式交付中真正向左移動，需要建立一個現代的安全外掛工具鏈及其在整個流水線中的擴充套件。
安全左移體現在：如果映象中存在任何漏洞，該過程應該在構建階段就停止。應該對 RBAC 進行定期審計以監控所有訪問級別。此外，所有工具和流程都應符合 CIS 基準。
採用安全即程式碼實踐（SaC）是一個不錯的方式，將 Kubernetes-native YAML 檔案的安全清單編寫為自定義資源定義。這些資訊是可讀的，並在執行時宣告應用程式的安全狀態。隨即可以將其推送到生產環境中並使用零信任模型進行保護。因此，流水線外的程式碼永遠不會有任何更改。
參考連結：
https://dzone.com/articles/securing-your-containers-top-3-challenges
https://www.businesswire.com/news/home/20220516005772/en/Insights-on-the-Container-Security-Global-Market-to-2027---Rising-Threats-and-Cybercrimes-to-Drive-Requirement-for-Container-Security-Platforms---ResearchAndMarkets.com
https://www.oreilly.com/library/view/container-security/9781492056690/ch01.html#ch_container_security