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

我建議從最基本的開始：理解容器安全是什么，并構(gòu)建模型來降低風(fēng)險(xiǎn)。

01遵循DevOps生命周期

安全計(jì)劃最終都會受到環(huán)境的限制，遵循標(biāo)準(zhǔn)的 DevOps 生命周期可以更好地發(fā)現(xiàn)模式和發(fā)揮協(xié)同效應(yīng)。
DevOps 的生命周期是一個無限迭代的過程：

• 計(jì)劃
• 編碼
• 構(gòu)建
• 測試
• 發(fā)布
• 部署
• 運(yùn)維
• 監(jiān)控

容器通過 Dockerfile 文件的形式包含在應(yīng)用程序中，但實(shí)際上并不是應(yīng)用程序的一部分。因此，計(jì)劃和編碼階段與容器無關(guān)。

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

• 構(gòu)建時：構(gòu)建、測試和發(fā)布
• 容器基礎(chǔ)設(shè)施：部署和運(yùn)維
• 運(yùn)行時：監(jiān)控

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

• 構(gòu)建時：CI/CD 基礎(chǔ)設(shè)施、容器注冊表；
• 容器基礎(chǔ)設(shè)施：容器編配器；
• 運(yùn)行時：生產(chǎn)環(huán)境。

現(xiàn)在我們有了三個風(fēng)險(xiǎn)評估著手點(diǎn)。

02構(gòu)建時安全

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

大多數(shù)供應(yīng)商在這個時候向你強(qiáng)調(diào)容器鏡像掃描的重要性。容器安全掃描的確很重要，但還不夠。

這個階段的目標(biāo)：最小化供應(yīng)鏈攻擊風(fēng)險(xiǎn)。

容器鏡像“衛(wèi)生”
首先，思考一下你的鏡像應(yīng)該是什么樣的，并重點(diǎn)關(guān)注依賴項(xiàng)是如何引入的：

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

所有這些檢查都是靜態(tài)的，可以很容易在構(gòu)建管道中實(shí)現(xiàn)。

容器鏡像掃描
然后，我們可以進(jìn)行容器鏡像掃描。

不要在構(gòu)建管道中掃描鏡像，而是在容器注冊表中進(jìn)行持續(xù)的掃描。

為什么要這樣？服務(wù)不一定會進(jìn)行不間斷的構(gòu)建，但漏洞會不斷出現(xiàn)。其次，構(gòu)建是增量的：每個構(gòu)建都將生成一個新鏡像。因此，假設(shè)你的容器編配器信任你的注冊中心，所以你發(fā)布的每個標(biāo)記總是可以部署并需要進(jìn)行評估。

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

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

03容器基礎(chǔ)設(shè)施安全性

容器基礎(chǔ)設(shè)施由負(fù)責(zé)從注冊表拉取鏡像并在生產(chǎn)環(huán)境中作為容器運(yùn)行的所有活動部件組成。

這主要是容器編配器——Kubernetes。
這一階段的目標(biāo)：

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

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

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

每一個復(fù)雜的平臺都很容易出現(xiàn)配置錯誤，而這正是你需要關(guān)注的部分。

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

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

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

• 網(wǎng)絡(luò)層
• 身份和訪問管理層（IAM）

網(wǎng)絡(luò)不應(yīng)該是平的。你可以先把所有東西分配到子網(wǎng)絡(luò)，然后建立起完整的服務(wù)網(wǎng)絡(luò)。

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

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

04運(yùn)行時安全性

最后一個是工作負(fù)載的安全性。到這個時候，大部分的強(qiáng)化工作都已完成，我們將進(jìn)入反應(yīng)性安全控制領(lǐng)域，也就是故障后（post-fail）。

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

探測和事故響應(yīng)
控制攻擊影響面最好的辦法是盡量縮短從入侵開始到安全團(tuán)隊(duì)收到警報(bào)之間的時間。

探測正在發(fā)生的漏洞是供應(yīng)商們爭相尋找解決方案的另一個領(lǐng)域?，F(xiàn)在有很多方法，其中大多數(shù)都需要使用邊車或守護(hù)進(jìn)程來主動監(jiān)控 Pod 流量和系統(tǒng)調(diào)用。

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

發(fā)生事故是不可避免的，不過這沒關(guān)系，只要你有相應(yīng)的事故響應(yīng)流程。

每次事后分析的第一個要點(diǎn)應(yīng)該是：“下次我們?nèi)绾胃斓匕l(fā)現(xiàn)這個問題”？搞清楚這些問題可以讓你發(fā)現(xiàn)自己的盲點(diǎn)，然后利用這些盲點(diǎn)來了解自己錯過了哪些信號，以及什么東西是值得相信的。

05結(jié)論

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

文章看完，還不過癮？
更多精彩內(nèi)容歡迎關(guān)注百度開發(fā)者中心公眾號

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。