docker_practice/security/daemon_sec.md
Ensky Lin a795bf863a 修正多個用詞
"s/程序/程式/g" "s/性能/效能/g" "s/如下/以下/g" "s/加載/載入/g" "s/獲取/取得/g" "s/服務器/伺服器/g" "s/信息/訊息/g" "s/註釋/註解/g" "s/裏/裡/g" "s/構建/建立/g" "s/配置/設定/g"
2014-11-24 22:54:30 +08:00

19 lines
2.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

## Docker服務端的防護
執行一個容器或應用程式的核心是透過 Docker 服務端。Docker 服務的執行目前需要 root 權限,因此其安全性十分關鍵。
首先,確保只有可信的使用者才可以訪問 Docker 服務。Docker 允許使用者在主機和容器間共享文件夾,同時不需要限制容器的訪問權限,這就容易讓容器突破資源限制。例如,惡意使用者啟動容器的時候將主機的根目錄`/`映射到容器的 `/host` 目錄中,那麽容器理論上就可以對主機的文件系統進行任意修改了。這聽起來很瘋狂?但是事實上幾乎所有虛擬化系統都允許類似的資源共享,而沒法禁止使用者共享主機根文件系統到虛擬機系統。
這將會造成很嚴重的安全後果。因此,當提供容器建立服務時(例如透過一個 web 伺服器),要更加註意進行參數的安全檢查,防止惡意的使用者用特定參數來建立一些破壞性的容器
為了加強對服務端的保護Docker 的 REST API客戶端用來跟服務端通信在 0.5.2 之後使用本地的 Unix 套接字機制替代了原先綁定在 127.0.0.1 上的 TCP 套接字,因為後者容易遭受跨站腳本攻擊。現在使用者使用 Unix 權限檢查來加強套接字的訪問安全。
使用者仍可以利用 HTTP 提供 REST API 訪問。建議使用安全機制,確保只有可信的網路或 VPN或證書保護機制例如受保護的 stunnel 和 ssl 認證)下的訪問可以進行。此外,還可以使用 HTTPS 和證書來加強保護。
最近改進的 Linux 名字空間機制將可以實做使用非 root 使用者來執行全功能的容器。這將從根本上解決了容器和主機之間共享文件系統而引起的安全問題。
終極目標是改進 2 個重要的安全特性:
* 將容器的 root 使用者映射到本地主機上的非 root 使用者,減輕容器和主機之間因權限提升而引起的安全問題;
* 允許 Docker 服務端在非 root 權限下執行,利用安全可靠的子程式來代理執行需要特權權限的操作。這些子程式將只允許在限定範圍內進行操作,例如僅僅負責虛擬網路設定或文件系統管理、設定操作等。
最後,建議采用專用的伺服器來執行 Docker 和相關的管理服務(例如管理服務比如 ssh 監控和程式監控、管理工具 nrpe、collectd 等)。其它的業務服務都放到容器中去執行。