作者 | Cloudberry
譯者 | 王者
策劃 | 萬佳
保證容器安全是一項復雜的任務。這個問題域很廣，面對大量的檢查清單和最佳實踐，你很難確定采用哪個解決方案。所以，如果你要實現容器安全策略，應該從哪里開始呢？

我建議從最基本的開始：理解容器安全是什么，并構建模型來降低風險。

01遵循DevOps生命周期

安全計劃最終都會受到環境的限制，遵循標準的 DevOps 生命周期可以更好地發現模式和發揮協同效應。
DevOps 的生命周期是一個無限迭代的過程：

• 計劃
• 編碼
• 構建
• 測試
• 發布
• 部署
• 運維
• 監控

容器通過 Dockerfile 文件的形式包含在應用程序中，但實際上并不是應用程序的一部分。因此，計劃和編碼階段與容器無關。

其余的每一個步驟都與容器安全有關，我對它們進行這樣的分組：

• 構建時：構建、測試和發布
• 容器基礎設施：部署和運維
• 運行時：監控

為什么要這樣分組？安全策略只有在能夠被實現的情況下才是有效的。每個分組中的每一個步驟都共享了一個公共設施，可以很容易往其中注入安全控制元素：

• 構建時：CI/CD 基礎設施、容器注冊表；
• 容器基礎設施：容器編配器；
• 運行時：生產環境。

現在我們有了三個風險評估著手點。

02構建時安全

在構建階段，我們輸入了一堆源文件和一個 Dockerfile，得到了一個 Docker 鏡像。

大多數供應商在這個時候向你強調容器鏡像掃描的重要性。容器安全掃描的確很重要，但還不夠。

這個階段的目標：最小化供應鏈攻擊風險。

容器鏡像“衛生”
首先，思考一下你的鏡像應該是什么樣的，并重點關注依賴項是如何引入的：

• 允許開發人員使用哪些基本鏡像？
• 依賴項是固定的嗎？是從哪里拉取的？
• 是否需要一些標簽來簡化監管和合規性?
• 檢查一下 Dockerfile。
  在編寫 Dockerfile 時遵循 Docker 安全最佳實踐。

所有這些檢查都是靜態的，可以很容易在構建管道中實現。

容器鏡像掃描
然后，我們可以進行容器鏡像掃描。

不要在構建管道中掃描鏡像，而是在容器注冊表中進行持續的掃描。

為什么要這樣？服務不一定會進行不間斷的構建，但漏洞會不斷出現。其次，構建是增量的：每個構建都將生成一個新鏡像。因此，假設你的容器編配器信任你的注冊中心，所以你發布的每個標記總是可以部署并需要進行評估。

這個時候你就要開始考慮補丁管理和保存期限：

• 補丁管理：根據掃描結果提供補丁，生成新版本鏡像；
• 保存期限：未修補 / 舊 / 不安全的鏡像將從注冊表中刪除。

03容器基礎設施安全性

容器基礎設施由負責從注冊表拉取鏡像并在生產環境中作為容器運行的所有活動部件組成。

這主要是容器編配器——Kubernetes。
這一階段的目標：

避免存在安全隱患的平臺配置錯誤

最大限度地減少來自受損容器的攻擊

基礎設施安全性：配置錯誤
容器編配器比較復雜，特別是 Kubernetes。到目前為止，它都沒有兌現 DevOps 的承諾。我認為，我們離成為不需要太多運維開銷的主流解決方案還有一兩個抽象層的距離。

每一個復雜的平臺都很容易出現配置錯誤，而這正是你需要關注的部分。

你必須對基礎設施進行威脅建模，確保它不會被攻擊。這個特殊的威脅模型應該關注每一個參與者，但受損的容器除外 (我們將在下面討論這個問題)。

這里我就不詳細講了，因為這取決于你運行的是什么平臺。對于 Kubernetes，建立威脅模型的一個著手點是這樣的。
https://www.marcolancini.it/2020/blog-kubernetes-threat-modelling/
此外，如果你還沒有這么做，可以考慮使用托管平臺：如果你可以利用 (受信任的) 供應商提供的模型，復雜性就會降低。

基礎設施安全性：橫向移動
接下來，我們來討論當一個容器被破壞時會發生什么。
你想要最小化攻擊者橫向移動的能力，專注于以下兩個層：

• 網絡層
• 身份和訪問管理層（IAM）

網絡不應該是平的。你可以先把所有東西分配到子網絡，然后建立起完整的服務網絡。

在 IAM 層，為每個容器使用單一的標識，以此來優化授權。這在多租戶平臺中尤其重要：如果沒有細粒度的身份標識，就不可能獲得最小權限。

最后，由于它們是不可變的，所以最好是減少容器可以運行的時間：攻擊者橫向移動并獲得持久性機會窗口等于容器運行生命周期。所以，持續關閉和滾動重啟你的容器。

04運行時安全性

最后一個是工作負載的安全性。到這個時候，大部分的強化工作都已完成，我們將進入反應性安全控制領域，也就是故障后（post-fail）。

這個階段的目標：將受損容器的攻擊影響降至最低。

探測和事故響應
控制攻擊影響面最好的辦法是盡量縮短從入侵開始到安全團隊收到警報之間的時間。

探測正在發生的漏洞是供應商們爭相尋找解決方案的另一個領域。現在有很多方法，其中大多數都需要使用邊車或守護進程來主動監控 Pod 流量和系統調用。

大多數解決方案都會提供一些價值，但我的建議是從簡單的開始，并進行迭代：使用現有的 SIEM，攝取來自平臺、應用程序和審計系統的日志。

發生事故是不可避免的，不過這沒關系，只要你有相應的事故響應流程。

每次事后分析的第一個要點應該是：“下次我們如何更快地發現這個問題”？搞清楚這些問題可以讓你發現自己的盲點，然后利用這些盲點來了解自己錯過了哪些信號，以及什么東西是值得相信的。

05結論

容器安全是一個廣泛存在的問題，不僅僅是掃描鏡像那么簡單。這就是我建立的模型，用于分析容器風險和解決方案。它比較抽象，當然，和所有模型一樣，它不一定是絕對正確的。我們都知道，每一個基礎設施就像是一片雪花：以此為靈感去建立你自己的威脅模型。
原文鏈接：
https://cloudberry.engineering/article/practical-introduction-container-security/

文章看完，還不過癮？
更多精彩內容歡迎關注百度開發者中心公眾號

總結

以上是生活随笔為你收集整理的容器安全最佳实践入门的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。