編者按：提到容器的安全性，多數人都說它不夠安全，但又不舍放棄其帶來的高性能和便捷性。本文作者認為Docker其實已經提供了一種安全模式，并且能和SeLinux、AppArmor等所有Linux的安全方案搭配使用，只是很多人沒有用好而已。作者通過將裸機、VMs和Container比作是建筑、公寓和私人房間，說明了這個問題。當然，從另一個角度來說，作者只考慮了單租戶的問題，對多租戶的情境，Container的安全性依舊不夠。以下問原文：
自去年開始，Linux容器就一直處于技術炒作的最前沿，各種關于容器安全的討論也隨處可見。在大部分發表的討論、文章和博客中，不管需要與否，與VMs的對比都不可避免。故事的真相更接近于“containers always”及“VMs sometimes”。 當然，也存在一些用戶，在使用Docker后開始重新評估VMs。而在大部分情況下，用戶更加偏向于性能而不是安全——單租戶環境中，在使用VM生命周期管理方式的同時，避免虛擬化的開銷無疑更加令人向往。
然而，對于那些依賴VMs實現安全的解決方案，Docker并不是替代，而是補充。
通常情況下，我更愿意將裸機、VMs和Container比作是建筑、公寓和私人房間。Linux容器可以存在于VM中，同樣它們也可以直接運行在裸機上。現實生活中可能存在幾個朋友共享一個公寓，他們分別使用自己的私人房間。但是毫無疑問，這和每個人擁有自己的公寓并不一樣。如果你想和幾個朋友共享一個公寓，那么這些人必須是你完全可信的。即使這樣，這種安全只在一定的條件下可以，同時是有限度的。
我和妻子結婚已經12年，有兩個孩子和我們生活在一起。我和妻子住在一個房間，而孩子住在另一間，還有第三個房間，是我的家庭辦公室。將孩子們放在一個單獨的公寓并沒有太大意義，就像在自己VM上增加一個OpenSSH守護進程將之與應用程序分離一樣。
孩子們有各自的私人房間，是未來讓他們不會賴在父母的床上，但結果卻差強人意（如果為3歲大的女兒準備自己的公寓，必然會觸發一個CPS應用）。
我的家庭辦公室是個禁止通行區域，就如我給這個房間配備了定制的防火墻，但是我的孩子仍然會進來，雖然不是經常。即使兩歲大的孩子都清楚那個是父親的空間，并且尊重這個設定。
容器就像是私人房間，在保護隱私方面是無價的——出于某些原因，在同一臺主機或者VM上經常需要混搭多個進程。而在容器環境下，這些進程已經被隔離了，VMs帶來的安全效益已不復存在。
這種容器之間松散的隔離并不是bug，而是一種有用的特性。我們假定容器中運行的進程運行在同一個VM上，那么在這些進程間實施嚴格、更細粒度的訪問控制是一件好事。
實際情況下，即使是在一個運行單進程的主機上，運行容器也有助于你的安全防護。誰能保證以后我們不會運行任何通用進程？比如通常主機上都會運行的syslogd、sshd等。這顯然不可能，在這里，我們可以假設有一個VM會直接加載一個網絡服務器作為它的初始化進程（PID 1）。
那么這個進程可能會造成什么樣的結果？它可以做什么？它是否可以發送原始網絡框架？是否可以提升到root權限？既然系統上存在setuid-root，它是否可以被提升權限？如果可以提升，那么它可以做什么？它是否可以進行DAC重寫，或者掛載文件系統，亦或是做其它只有root權限用戶才可以進行的事情？
肯定的是，SeLinux可以被用于保護你的進程。但是相信不少DevOps工程師都將SELinux禁用了，并且沒有多少人重寫過自己的SELinux策略，甚至讀過SeLinux策略的人都很少。時至今日，當下的Linux系統中又會有多少使用了SeLinux作為Docker的默認安全策略呢？這里的阻礙又是什么？
不錯，你的應用程序可以放棄這些特權，但是你需要的應用程序及開發者做一些正確的事情。當然，你還可以選擇使用一個包裝盒，也就是Docker做的事情。
換個角度說：即便使用了VM，也不意味著你可以在主機上運行“chmod -R 777 /”。你的系統提供了進程所需要的安全政策，但是你可能并沒有使用它們。Docker就是提供了這個功能的工具，在最大程度上的開箱即用。
毫無疑問，不管是從工具的角度還是文化的角度來說，上述問題正是DevOps成敗的關鍵。而對于許多機構來說，“DevOps”通常是“soft ops”（軟件層面上的Ops）。對比以往，開發者在建立和部署應用程序時有了更多的特權，尤其是在一個VM內時。這也導致了關注點的分離，通常hard-ops（硬件Ops） 工程師只負責硬件和網絡基礎設施的健康。而對于那些運行AWS或者GCE上的服務，更是將hard-ops外包給了Google和AWS。
hard-ops工程師，傳統系統管理員，以及安全工程師，他們過去通常做的事情是應用程序部署工作，以及幫助評估安全問題。在有些機構，他們可能仍然從事這樣的事情。但毫無疑問的是，開發者使用self-provisioning-in-a-bubble模式的機構數量正在增加。
不幸的是，在DevSecOps（或者說是SecDevOps）上并沒有太大的進步。同時，隨著DevOps向“No Ops”的傾斜，人們對安全上的關注可能在日漸減弱。
Docker作為一個DevOps工具，通過為用戶提供一種安全模型，同時也讓模型更容易及便捷的被調整，而在改變這種現狀。Docker將安全切實的轉交到開發者手中，讓他們避免搬起石頭砸自己的腳。
使用Docker，用戶將默認獲得嚴謹的功能集，而獲得這個能力僅僅需要調整一些命令行參數。同時，對比以往閱讀Linux系統調用手冊后再膽戰心驚的調試，你只需要在運行時設置一個簡單的標記（或許在將來，這個操作可以通過Dockerfile更便捷的完成）。
容器安全肯定不會優于一個使用sys_setcap()做良好安全保障的應用程序，但是對于容器來說，它不與任何其他最佳實踐沖突。它與VMs并不矛盾，可以良好的配合運行。同時，它與SeLinux或者AppArmor也不沖突，同樣可以良好的搭配使用。事實上，使用之后你會發現，所有Linux中存在的安全方案都可以通過Docker進行。
京公網安備 11010502049343號