[[171006]]

應用開發中迅速增長的虛擬化容器方式鞏固加深了其在生產環境IT管理者心目中的地位。盡管看起來與虛擬機相似，但兩者相比還是有一些核心差異，這些差異促使IT部門重新審視已有的安全策略。

越來越多的IT部門正在被迫放棄已有的全棧虛擬機應用部署方式。應用運行在大量進程上，這些進程需要靈活可控。而在虛擬機中，如果進程發生變化，整個虛擬機的運行需要更改。

虛擬機通常基于傳統的單片應用模型，而容器則能對復合應用模型提供更好的支持。

虛擬機具備了運行一個應用程序所需要的全部資源，包括應用程序、數據庫、數據分析、虛擬化的硬件資源、BIOS以及應用正常工作所需要的所有服務。因此，每個虛擬機都是一個完整的系統，而虛擬機的安全策略在本質上與一個物理機系統完全相同。由于虛擬機是一個全棧系統，它的缺點是每當啟動一臺虛擬機，意味著啟動BIOS，接著啟動操作系統，然后啟動余下的所有相關應用軟件。雖然這個啟動過程基于一系列虛擬化資源，比物理機啟動快，但是并不足以快到能瞬時啟動，除非使用事先預置好的熱虛擬鏡像(虛擬機快照)，但是這種啟動方式需要使用額外的存儲資源，導致資源浪費。虛擬化容器則沒有這些方面的問題。

容器更多依賴于容器外部，而不是容器本身。盡管也是從物理層創建的抽象實例，但虛擬化容器以動態的方式共享大部分資源，每個容器通過底層平臺訪問大部分的設備。容器化概念更接近于應用程序的使用方式，它假設BIOS和系統已經運行了，因此無需像虛擬機一樣再次啟動。容器化技術利用共享資源創建了一個寬松的沙盒環境，每個容器在上面構建函數、服務或者應用。

在虛擬化容器中，應用程序可以被劃分成多組容器化的功能，它們合力運行，構成的系統能夠以更加靈活多變的方式提供進程。一個復合應用可以由一個專門配置并優化用于執行數據分析的容器，和一個專用的數據庫或者應用邏輯協同組合而成。容器在這種服務鏈管理方面優于虛擬機，因為它基于一個共享平臺工作，在使用共享的功能、設備方面比虛擬機更有效率。

更高的靈活性意味著需要更多的安全性

盡管容器的使用增加了整體的靈活性，它也引入了額外的管理需求以及安全問題。在虛擬機中，所有組件都在同一個地方，虛擬機可以作為一個獨立實體進行管理和安全防護。與此不同的是，對于基于容器的應用，組成應用的一系列功能都是松耦合在一起，因此需要對每一個分別進行管理和安全防護。

如果底層平臺的安全防護不到位，那么在其基礎上搭建的所有容器的安全都得不到保證。反過來的情況也是一樣。我們假設一個容器鏡像擁有完整的超級用戶權限。因為容器需要持續地跟底層平臺交互，一個有權限訪問容器的入侵者，理論上就可以通過容器化環境攻破底層平臺，從而獲得底層平臺的訪問權限。

盡管前面描述的情況聽起來像是一個非常嚴重的設計缺陷，但這是容器運行的必要條件，也是其核心特點，正是這個特點使得容器能夠比虛擬機提供給開發人員更多的功能提升潛力，吸引了大量產品開發的關注。生產環境IT系統選擇采用容器技術需要確保兩個關鍵問題，既要能保證容器自身內部的安全性，又要能保證容器化環境創建方式的安全性。

保證虛擬化容器的安全性必然是任何使用容器的群體的高優先級任務。在可能的情況下，通過使用各自的命名空間來隔離容器。為每個虛擬化容器提供獨立的網絡堆棧，避免任何特殊權限的訪問能夠穿過多個不同的容器再到達物理端口。使用控制組管理資源分配和利用——這種方式加強了外部安全性，因為它能夠有助于預防分布式DOS攻擊。

使用虛擬化容器的一些建議

僅僅在非常必要的時候才能使用虛擬容器的增強權限，并且在不需要該權限時立即切換回標準權限。為以防萬一，在不使用的時候，永遠不要將權限設置為增強權限;每次提升權限和重置回標準權限所產生的額外內部處理時延是值得的，因為這種做法能增強整個IT平臺的安全性。

嘗試用非root的權限運行服務：如果必須使用root權限，一定要與在物理IT基礎設施上使用root權限一樣小心。容器并不是一個沙盒，它存在各種各樣的可與外部交互的方法。開發者并不是在一個密封空間里面開發，一個容器里面任何糟糕的代碼可能會對同一物理平臺上所有其他容器都產生嚴重的安全影響。絕大多數容器不需要root權限。大部分需要root權限的服務應該在容器外部的更底層平臺運行。以低權限運行容器能夠阻止任何類型的掛載請求，拒絕創建文件或者修改屬性，防止模塊裝載，達到保護系統的目的。

底層平臺對容器的安全性處理與傳統虛擬化不一樣，這個主要區別正是虛擬化容器的核心功能所在。對于Docker來說，Docker后臺守護進程(Docket Deamon)在物理平臺的root環境中擁有全部權限，并使用該權限創建虛擬化的容器環境。任何有權限訪問該后臺守護進程的用戶就能完全自由地做任何想做的事情。因此，必須只能通過專用的系統管理員權限控制方法來控制訪問后臺守護進程。

虛擬容器安全性也包括監控容器如何使用API。API調用中的非常小的錯誤有可能導致惡意攻擊，例如啟動新的容器或者改變現有API調用，使之以很高的權限訪問root環境。當企業系統在使用容器時，需要在API監控和管理方面做一些投入，比如采用Akana、Apigee或者CA Technologies公司的產品。