容器安全與DevSecOps：一些不再適用的舊規則

本文講的是容器安全與DevSecOps：一些不再適用的舊規則【編者的話】如何保證容器環境的安全性，從根本上保證杜絕未授權的變更呢？作者認為，將安全控制流程的時間提前是一個不錯的辦法。

【深圳站｜3天燒腦式Kubernetes訓練營】培訓內容包括：Kubernetes概述、架構、日誌和監控，部署、自動駕駛、服務發現、網路方案等核心機制分析，進階篇——Kubernetes排程工作原理、資源管理及原始碼分析等。

有關容器環境的一個常見問題是，如何保證只有授權過的映象才能作為容器執行呢？各種產品和開發團隊在這個問題上花了不少心思，想要把軟體和配置的那一套標準應用到容器管理中。

在傳統的IT環境中，有兩個程式可以並行：一個是軟體開發（dev.），另一個是軟體執行環境的基礎設施運營（ops.）。針對這兩個程式，已經有成熟的安全控制措施。

• 靜態程式碼分析工具通過評估原始碼，檢查常見錯誤，規範編碼標準來保證軟體開發安全
• 伺服器評估工具通過檢查作業系統和其他元件的版本，掃描漏洞和補丁級別，規範配置標準來保證基礎設施運營的安全

上述兩個過程獨立進行，只有當新開發的軟體安裝到基礎設施上之後，二者才有交集。最重要的是，如果基礎設施配置出了問題，基本上會在安全控制和運營過程中得到妥善處理，很少會影響到軟體開發。

為了保證程式碼安全，第一步並不是簡單的將其過渡到容器應用中，之後的控制步驟需要根據容器化環境進行調整。

容器：新的規則，新的安全流程

容器把所有的作業系統元件、必備元件和相關設定都嵌入到映象當中。一旦映象被建好和傳輸（ship），之後就不應該再有變動。執行狀態的容器不允許調整配置、修補和替換元件。修改映象內部環境的唯一方式就是重建新映象。

這就是說，基礎設施的安全方法唯一可以應用到的地方就是在映象的建立過程中。因為一旦映象完成部署，就沒有改動的餘地。

安全問題需要引起重視

嵌入基礎設施的安全控制在很大程度上，或者說是在根本上改變了建立流程。這種方式把當前的安全控制流程完全的轉移了。

不用等到開發和一體化程式完成後再進行迭代評估、修補和配置調整，安全控制需要在第一時間進行，即在映象建立之後，在進一步的CI/CD（持續整合和持續交付）過程之前。這就是“把安全控制挪到前面來”這句話表達的真正意思。

在此過程中，需要執行基礎設施安全方針中的所有要素，這點非常重要，同時，還有一些針對容器映象的方針：

• 根據基準映象（模板）建立映象
• 伺服器軟體元件可以接受一定程度上的漏洞
• 伺服器軟體元件是滿足條件的最低版本 映象作業系統的配置滿足組織標準
• 映象後設資料包括要求元素、使用者環境設定和入口點設定。

理想情況下，這些方針與當前的物理、虛擬或者雲上的主機中所應用的是對應的。例如，映象不可接受的漏洞清單和評估伺服器合規性的漏洞清單基本上是一樣的。

是時候更新安全控制了

很久以來，安全組織都在關注未授權的變更。跳轉伺服器、特權身份管理、管理日誌、變更視窗以及根因分析，這些手段都是為了檢測和防止對軟體元件及其配置進行未授權的變更。對主機進行內部和外部雙重連續漏洞評估，是為了能及時衡量IT基礎設施中不可避免的變更。

容器化環境的實現看起來不太現實。它同時要求動態性和一致性。有了容器之後，主機不再是必須的，因為主機已經沒有有效荷載或配置的意義了（容器引擎除外）。同時，對執行中的容器進行變更也不再是必須的，因為當編排或重新建立容器會覆蓋掉這些變更。總之，以後再也不用進行傳統意義上的變更了。

在需要進行變更的地方，只需要重新構建新的映象來替代、增加或是修補想要改動的容器，使之切合預期。如果把安全控制引入這一過程並能夠有效運作，之前覺得不可能的事情就會得以實現：在根本上創造了更多的安全應用，比以往更快更高效。

原文連結：Container Security and DevSecOps: The Old Rules No Longer Apply（翻譯：馬遠征)

原文釋出時間為：2017-04-24

本文作者：馬遠征

本文來自雲棲社群合作伙伴Dockerone.io，瞭解相關資訊可以關注Dockerone.io。

原文標題：容器安全與DevSecOps：一些不再適用的舊規則