當面對容器技術時，安全性往往是人們最為關注的問題。開發人員喜愛容器，某些運維人員也對其贊賞有加。但如果使用不當，其是否會帶來安全隐患？我們熱愛容 器方案的各類天然特性，但在安全性方面其是否會同時成為一種短闆？在今天的文章中，我希望帶領大家了解一些圍繞容器進行的深度安全保障機制。由于本文專門 針對容器系統，是以我不會拿出篇幅讨論主機節點或者通過禁用linux守護程序減少攻擊面之類的議題。
隻讀容器系統（docker 1.5）
首先，我們可以運作隻讀容器系統。通過指定--read-only， 容器的rootfs将以隻讀方式啟動，這樣容器當中的任意程序都無法對容器本身進行寫入操作。這意味着當我們由于應用中存在安全漏洞而出現檔案上傳行為 時，其會由于容器rootfs的隻讀屬性而被阻斷。這同時也會阻止應用向rootfs内寫入日志記錄，是以我們可能需要利用遠端日志記錄機制或者指定分卷 來完成相關寫入操作。
使用方法（docs）：
很多人都在熱切期盼着這項功能。目前，擁有容器的root權限意味着我們在主機上同樣擁 有root權限。如果我們能夠在自己的容器當中實作/bin，那麼也同樣能夠将任何預期内容添加進來，甚至徹底控制主機系統。而随着user- namespace的引入，大家将能夠在保證使用者在容器内擁有root權限的前提下，利用uid:gid保證對應的使用者/群組在容器之外處于非高權限狀 态。作為第一階段，我們現在可以對每個域執行個體中的root進行重新映射。作為發展的下一階段，我們可能會進行全局映射以及每容器映射，不過這樣的能力是否 必要仍在讨論當中。
seccomp（git主分支）
在命名空間的幫助下，我們已經能夠實作權限分享。但除此之外，我們還需要對容器當中能夠運作的具體負載 進行控制。這時就需要依靠seccomp了——所謂seccomp，其實就是安全計算模式的縮寫。它允許大家對系統調用進行篩選，這樣我們就能夠為應用程 序定義其需要的系統調用，并拒絕其它一切不必要的調用行為。下面例舉一個簡短的socket.json執行個體：
其運作結果将如下所示：
nautilus項目
目前docker生态系統中的一項重要功能缺失就是對鏡像内容的檢查。此前曾有文章指出，當下docker hub中超過30%的官方鏡像存在着常見安全漏洞，這一消息旋即引起軒然大波。docker方面立即着手處理，而且現在各被釋出在docker hub中的官方鏡像在正式推出前都需要進行掃描。在本屆dockercon歐洲大會上，docker方面公布了nautilus項目，這是一項官方提供的 鏡像掃描服務，能夠讓我們更為輕松地建構并使用高完整性内容。
目前關于nautilus項目還沒有太多官方說明，不過我們了解到其運作在背景當中，而且docker方面表示他們已經借此對超過7400萬條 pull進行了保護。最近，他們還發起了一項調查，征求使用者們的實際使用需求。在這裡我隻能先為大家提供一些假設。首先，docker方面表示該項目能 夠：
保障鏡像安全
實作元件庫存/許可管理
實作鏡像優化
實作基礎性功能測試
以下是幾項可能即将實作的特性：
以内部方式運作nautilus
針對單一鏡像或者單一部署節點進行計費
apparmor配置檔案
通過使用apparmor，大家可以借助配置檔案對功能進行限制。配置檔案可以實作極為出色的控制粒 度，但很多人并不希望把時間耗費在編寫配置檔案方面。考慮到這類配置檔案對docker容器運作的重要意義，jessie frazelle作為docker的核心維護者之一，創造了bane以簡化配置檔案的編寫難度。它能夠使用toml輸入檔案，并生成及安裝 apparmor配置檔案。該配置檔案随後可以被用于運作docker容器，且采用與之前相同的文法：
這一切都能夠幫助我們實作容器安全保障，當然docker自身也在努力降低相關方案的執行難度。這意味着如果大家希望了解與本議題相關的各類細節資訊，可以點選此處檢視github的對應分區并擷取各類最建立議。
====================================分割線================================