基於DevOps的容器安全實踐

每個安全計劃都會受到可實施安全控制措施的限制，DevOps生命週期是以下各項的無限迭代：計劃、編碼、構建、測試、釋出、部署、運維、監控

在應用程式中容器以Dockerfiles的形式來表達，但實際上Dockerfiles並不是容器的一部分(計劃和編碼)。從安全性的角度來看，容器安全主要涉及以下三部分，六個階段：

構建時：構建，測試和釋出

容器基礎架構：部署和運維

執行時：監控

每個安全策略只有在可以實施的情況下才有效。每個部分中的各個步驟可以實施安全控制措施：

構建時：CI/CD基礎結構，容器登錄檔

容器基礎設施：容器編排器

執行時：生產環境

在容器構建時，輸入了一堆原始檔和一個Dockerfile，輸出為Docker映象。該階段有很多安全和雲廠商提供了很多安全方案和映象安全掃描工具。容器安全掃描非常重要，是的，光映象掃描還遠遠不夠。本部分的安全目標是最小化供應鏈攻擊的風險。

首先，檢查映象的基礎，重點是檢查要引入的依賴項：

允許開發人員使用的基本映象。

固定軟體依賴性，依賴所要拉取的源。

是否需要透過標籤來簡化治理和合規性?

整理Dockerfile。

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

然後,下一步就是掃描容器映象。

不要在構建管道中掃描映象，而是在容器登錄檔中設定連續掃描。

漏洞可能早就存在，如果在構建時才檢查有點遲了。其次，構建是疊加的：每個構建都會生成一個新映象。因此，透過掃描信任登錄檔，釋出的每個標籤都可以信任，而無需重複在每次構建時候都檢查。最後由於映象掃描需要時間，如果在構建時候掃描會影響構建的效能。

也可以考慮定義補丁程式管理和保質期流程：

補丁程式管理：掃描結果提供補丁程式，從而產生新版本的映象

保質期：對於超過期限未修補/舊/不安全的映象從登錄檔中予以刪除。

本階段可參考的工具：開源工具有Anchore,Clair,Dagda，商業化軟體有Atomic和Docker Cloud。

容器基礎結構由所有移動部件組成，這些部件負責從登錄檔中提取映象並將其作為容器在生產環境中執行。

主要是容器編排器有 kubernetes，Swarm。

本部分的目標有兩個：避免由於平臺配置錯誤帶來安全隱患;最小化來自受感染容器的攻擊擴充套件。

容器編排器非常複雜，特別是K8S。截至目前，它們還沒有實現DevOps的承諾。每個複雜的平臺都容易配置錯誤，這是我們要關注的部分。

必須對基礎架構進行威脅建模，以確保其不會被濫用。這個特定的執行緒模型應該專注於每個角色，但容器除外。取決於執行情況。對於K8S而言，這進行威脅建模的一個很好的起點。

也可以使用託管平臺，可以與(受信任的)供應商一起使用共享責任模型，則可以降低複雜性。

接下來，我們要將討論容器被破壞時會發生什麼。我們希望最大程度地減少攻擊者橫向擴充套件的能力，重點是兩個方面：網路和身份和訪問管理。

容器網路圖省事而放通設定。可以先將所有內容嚴格劃分為子網，然後逐步發展為完整的服務網路。

在IAM層上，朝著每個容器具有單一標識的方向進行操作，以微調授權授權。這在多租戶平臺中尤其重要：沒有精細的身份，就不可能獲得最低特權。

容器基礎不變的，可以透過週期性關閉舊容器，新起容器的方法，避免長期執行的容器來減少攻擊者橫向擴充套件並獲得永續性注入點。

本部分可以使用的開源工具有Habitat.sh，firejail等。

最後一方面是正在執行的工作負載的安全性。本階段目標是儘量減少從受損的容器的攻擊。

控制攻擊影響的最佳方法是最大程度地減少從漏洞發生到安全團隊收到警報的時間。

檢測到持續的違規行為是有大量供應商大量解決方案的領域。有許多方法，其中大多數將需要邊緣節點和守護程式集來主動監視pod的流量和系統呼叫。

建議是快速開始並反覆進行迭代完善：使用現有的SIEM，提取平臺，應用程式和稽核日誌。

肯定會有事件發生，然後對其進行響應處理，積累經驗：

時常考慮這樣的問題："下次如何更快地檢測到這種況?"這能使我們識別盲點，然後將其用於瞭解缺失的環節以及建立更完善的策略。

本部分可以使用的開源工具有Sysdig falco, OpenSCAP，Grafeas等。

容器安全性是一個廣泛的問題，而不僅僅是掃描映象。透過建立並用於推理容器風險和解決方案的模型才能全面完整的考慮到所有方面，當然和所有模型一樣，需要不斷實踐迭代完善，才能建立完善的容器安全模型。

原文來自：

本文地址： https://www.linuxprobe.com/devops-containers.html