無論大家是否知情，相信已經有相當數量的軟體(或者虛擬)容器執行在您的企業當中，甚至開始在生產環境中發揮作用。遺憾的是，多數安全團隊仍不瞭解容器技術的安全含義，甚至不清楚自家環境中是否存在容器因素。

總體來講，Docker與CoreOS Rkt等容器技術能夠對應用進行虛擬化——而非完整伺服器。容器具備出色的輕量化優勢，且無需複製訪客作業系統。其靈活、可擴充套件且易於使用，同時能夠在單一物理基礎設施內納入更多應用。由於使用共享式作業系統而非單一系統，因此容器往往能夠在瞬間完成引導(虛擬機器則普遍需要數秒乃至數分鐘)。

考慮到開發者與DevOps團隊已經廣泛接納容器技術，我們必須直面由此帶來的負面影響——即容器帶來了新型安全挑戰。

1. 引入存在漏洞的原始碼: 由於容器技術多為開源專案，因此開發者建立的映象需要經常更新，以備必要時使用。這意味著可能帶來程式碼受控性薄弱、存在漏洞或者引發意外狀況等問題。

2.  增大攻擊面：

3. 缺乏可觀察性: 容器由容器引擎負責執行，例如Docker或Rkt，同時與Linux核心相對接。由此帶來的全新抽象層將導致我們很難發現特定容器中的活動或者特定使用者在其中執行的操作。

4.  Devops速度:

5.  容器間干擾: 容器可彼此協作以用於建立DoS攻擊。例如，反覆開啟巢狀會快速導致整體主機裝置陷入卡頓並最終宕機。

6. 容器突破主機: 容器可作為root使用者執行，這使其能夠利用高許可權以突破“圍堵”及訪問主機作業系統。

7. 橫向網路攻擊: 單一容器的破壞可能導致其所在整體網路遭遇入侵，特別是在對外網路連線且原始巢狀執行未作適當限制的情況下。

考慮到以上幾點，我整理出了這份最佳實踐列表，希望能夠為大家的容器安全保障工作帶來啟示。

1. 採用綜合性漏洞管理方案。

安全漏洞管理工作絕不僅限於掃描映象，還需要貫穿整個容器開發週期進行訪問控制並配合其它策略，否則很可能導致應用崩潰或者執行時入侵。嚴格的漏洞管理方案應該利用主動性多項檢查完成“從搖籃到墳墓”的全面監控，同時利用自動觸發機制控制開發、測試、分段與生產環境。

2. 確保僅在環境中執行獲准映象。 

在開發環境中控制所引入之容器映象能夠有效縮小攻擊面並預防開發者造成致命安全錯誤。這意味著僅使用獲准註冊映象及對應版本。舉例來說，大家可以將單一Linux發行版指定為基礎映象，並藉此最大程度控制潛在攻擊面。

3. 實施貫穿整個生命週期的主動完整性檢查。 

作為容器生命週期安全管理中的重要組成部分，我們需要確保登錄檔中的容器映象具備理想的完整性，同時在映象進行變更或者凙時執行進一步控制。映象簽名或指紋可提供一套保管鏈，幫助大家輕鬆驗證容器完整性。

4. 在執行時強制執行最低許可權原則。 

作為一項基礎性安全最佳實踐，其同樣適用於容器技術。在攻擊者利用漏洞時，其通常能夠獲取已入侵應用或程序的訪問及其它操作許可權。確保容器始終僅具備最低許可權能夠顯著降低入侵後引發的暴露風險。

5. 為容器允許訪問或執行的檔案及可執行檔案設定白名單。 

白名單能夠幫助大家控制並管理檔案與可執行檔案，同時確保其僅在需要特定功能時得以使用。如此一來，我們的環境將更加穩定可靠。建立預核准或者白名單機制能夠顯著縮小攻擊面，同時作為基準參考防止容器干擾及容器入侵等問題。

6. 在執行中的容器上進行網路隔離。 

維持網路隔離性以按照應用或者工作負載進行容器叢集或者容器區劃分。這一舉措除了屬於高效最佳實踐外，還屬於受PCI DSS管理的必備容器應用原則，同時亦可預防橫向攻擊活動。

7. 主動監控容器活動及使用者訪問。 

與其它IT環境一樣，大家同樣需要對容器生態系統進行活動與使用者訪問監控，從而快速發現異常或者惡意活動。

8. 記錄全部管理使用者訪問活動以進行審計。 

雖然強大的使用者訪問控制機制能夠限制大多數人-容器互動操作，但管理員無疑不在受控範圍之內。因此，我們必須設定日誌管理以記錄各類管理性操作，從而在必要時提供取證資訊以及明確的審計線索。

儘管相較於其它早期解決方案，容器技術的安全性水平天然更高。然而由於其誕生時間還不長且已經得到廣泛普及，因此我們必須將主動檢測與響應方案納入管理體系以保障容器安全。另外，雖然容器安全相關知識已經得到高度重視，但大量容器特定漏洞已經開始出現，且這種不利趨勢在未來還將繼續持續下去。

好訊息是，容器技術在發展之初就能夠將強大的安全自動化控制能力結合至容器環境內。但壞訊息是，安全團隊需要針對這一新型技術做好準備，同時加強學習以及早意識到潛在的安全改進空間。不過發現問題正是解決問題的必要前提，因此意識到其重要性的朋友們已經在保障容器安全方面邁出了重要一步。

原文標題：8 Docker security rules to live by，原文作者：Amir Jerbi