Docker容器為應用的編寫、分發(fā)和部署帶來真正翻天覆地的變化。容器的目的是靈活性，讓應用可按需啟用，無論何時以及何地。當然無論我們在哪里使用應用，我們都需要數據。

對于數據應該如何映射到容器主要有兩個流派。***個流派稱我們將數據保留在容器中;第二個稱我們在容器外保存***性數據，這些數據可超越任何單個容器的使用壽命。在這兩種情況下，安全問題給數據和容器管理帶來大問題。

[[184096]]

▲Image: Pexels/Pixabay

管理數據訪問

現在有很多技術可用于分配存儲到Docker容器。臨時存儲容量，本地到運行容器的主機，可在運行時分配到容器。存儲卷存儲在映射到應用的特定子目錄的主機內。卷可在容器實例化時創(chuàng)建，或者使用“docker volume”命令提前創(chuàng)建。

另外，本地存儲可作為安裝點映射到容器。在這種情況下，“docker run”命令可指定本地目錄作為容器內的安裝點。第三種選擇是使用存儲插件直接關聯外部存儲與容器。

開放訪問

在每種方法中，Docker框架都沒有提供針對數據的內在安全模型。例如，任何主機目錄可安裝到容器，包括敏感系統(tǒng)文件夾，例如/etc。這意味著容器可能修改這些文件，因為使用標準簡單的Unix權限設置來授予權限。對此，另一種更好的做法是使用非根容器，這涉及在不同的Linux用戶ID(UID)下運行容器。這比較容易做，但這意味著構建一種方法來保護每個容器，使用組ID(GID)或者UID作為權限檢查。

在這里我們遇到另一個問題：使用非根容器，而本地卷無法正常工作，除非用于運行容器的UID有權限訪問/var/lib/docker/volumes 目錄。如果不這樣做，數據無法訪問或創(chuàng)建。打開這個目錄會有安全風險;然而，并沒有固有方法來按卷設置單獨的權限。

如果我們看看外部存儲如何安裝到容器，很多解決方案只需向運行容器的主機展示塊設備(LUN)以及格式化文件系統(tǒng)。這隨后展示到容器作為安裝點。在這一點上，目錄和文件的安全性可在容器內設置，減少我們已經討論的問題。然而，如果這個LUN/volume在其他地方重復使用，則對其如何安裝和使用沒有安全控制，因為沒有安全模型直接構建到容器/卷映射關系。一切都取決于信任主機上運行的命令。

這里還有一個問題：缺乏多租戶性。當我們運行容器時，每個容器實例可能為單獨的應用運行。在傳統(tǒng)存儲部署中，分配到容器的存儲應該有一定程度的分離，以確保數據不會被無意或惡意訪問。目前沒有簡單的方法在主機級別做到這一點，只有信任編排工具來運行容器以及映射到數據。

尋找解決方案

這里有些問題是特定于Linux/Unix。例如，安裝命名空間的抽象化為我們的數據提供了不同的入口點，然而，并沒有權限的抽象化--我無法映射用戶1000到用戶1001-如果沒有物理升級與每個文件及目錄相關的ACL(訪問控制列表)數據。大規(guī)模ACL變更可能會影響性能。對于本地卷來說，Docker可簡單地設置主機目錄的權限，新卷匹配正在啟動容器的UID。

外部卷提供了很好的機會，讓我們可以從運行容器主機中的權限結構轉移。然而，這意味著我們需要一種機制來映射卷數據到特定容器實例中已知可信應用。請記住，容器并沒有固有的“身份”，可根據意愿開始和停止。這使得它很難確定任何單個容器是否是數據卷的所有者。

目前主要解決方案是依靠編排平臺來管理容器的運行。我們信任這些系統(tǒng)來映射卷和容器，在很多方面，這并不像傳統(tǒng)SAN存儲或者虛擬磁盤映射到虛擬機那樣。但容器的區(qū)別在于其可便攜性，以及需要安全機制延伸到公共云。

我們仍然有很多工作要做。對于Docker，對存儲初創(chuàng)公司Infinit的收購可能啟發(fā)他們如何保護持久性數據。這應該可能意味著開發(fā)接口讓所有供應商可致力于此。