mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-03-12 12:51:08 +00:00
修正多個用詞
"s/程序/程式/g" "s/性能/效能/g" "s/如下/以下/g" "s/加載/載入/g" "s/獲取/取得/g" "s/服務器/伺服器/g" "s/信息/訊息/g" "s/註釋/註解/g" "s/裏/裡/g" "s/構建/建立/g" "s/配置/設定/g"
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
# 安全
|
||||
評估 Docker 的安全性時,主要考慮三個方面:
|
||||
* 由內核的名字空間和控制組機制提供的容器內在安全
|
||||
* Docker程序(特別是服務端)本身的抗攻擊性
|
||||
* Docker程式(特別是服務端)本身的抗攻擊性
|
||||
* 內核安全性的加強機制對容器安全性的影響
|
||||
|
||||
@@ -3,6 +3,6 @@
|
||||
|
||||
它提供了很多有用的特性;以及確保各個容器可以公平地分享主機的內存、CPU、磁盤 IO 等資源;當然,更重要的是,控制組確保了當容器內的資源使用產生壓力時不會連累主機系統。
|
||||
|
||||
盡管控制組不負責隔離容器之間相互訪問、處理數據和程序,它在防止拒絕服務(DDOS)攻擊方面是必不可少的。尤其是在多使用者的平臺(比如公有或私有的 PaaS)上,控制組十分重要。例如,當某些應用程序表現異常的時候,可以保證一致地正常執行和性能。
|
||||
盡管控制組不負責隔離容器之間相互訪問、處理數據和程式,它在防止拒絕服務(DDOS)攻擊方面是必不可少的。尤其是在多使用者的平臺(比如公有或私有的 PaaS)上,控制組十分重要。例如,當某些應用程式表現異常的時候,可以保證一致地正常執行和效能。
|
||||
|
||||
控制組機制始於 2006 年,內核從 2.6.24 版本開始被引入。
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
## Docker服務端的防護
|
||||
執行一個容器或應用程序的核心是透過 Docker 服務端。Docker 服務的執行目前需要 root 權限,因此其安全性十分關鍵。
|
||||
執行一個容器或應用程式的核心是透過 Docker 服務端。Docker 服務的執行目前需要 root 權限,因此其安全性十分關鍵。
|
||||
|
||||
首先,確保只有可信的使用者才可以訪問 Docker 服務。Docker 允許使用者在主機和容器間共享文件夾,同時不需要限制容器的訪問權限,這就容易讓容器突破資源限制。例如,惡意使用者啟動容器的時候將主機的根目錄`/`映射到容器的 `/host` 目錄中,那麽容器理論上就可以對主機的文件系統進行任意修改了。這聽起來很瘋狂?但是事實上幾乎所有虛擬化系統都允許類似的資源共享,而沒法禁止使用者共享主機根文件系統到虛擬機系統。
|
||||
|
||||
這將會造成很嚴重的安全後果。因此,當提供容器建立服務時(例如透過一個 web 服務器),要更加註意進行參數的安全檢查,防止惡意的使用者用特定參數來建立一些破壞性的容器
|
||||
這將會造成很嚴重的安全後果。因此,當提供容器建立服務時(例如透過一個 web 伺服器),要更加註意進行參數的安全檢查,防止惡意的使用者用特定參數來建立一些破壞性的容器
|
||||
|
||||
為了加強對服務端的保護,Docker 的 REST API(客戶端用來跟服務端通信)在 0.5.2 之後使用本地的 Unix 套接字機制替代了原先綁定在 127.0.0.1 上的 TCP 套接字,因為後者容易遭受跨站腳本攻擊。現在使用者使用 Unix 權限檢查來加強套接字的訪問安全。
|
||||
|
||||
@@ -13,6 +13,6 @@
|
||||
|
||||
終極目標是改進 2 個重要的安全特性:
|
||||
* 將容器的 root 使用者映射到本地主機上的非 root 使用者,減輕容器和主機之間因權限提升而引起的安全問題;
|
||||
* 允許 Docker 服務端在非 root 權限下執行,利用安全可靠的子程序來代理執行需要特權權限的操作。這些子程序將只允許在限定範圍內進行操作,例如僅僅負責虛擬網路設定或文件系統管理、配置操作等。
|
||||
* 允許 Docker 服務端在非 root 權限下執行,利用安全可靠的子程式來代理執行需要特權權限的操作。這些子程式將只允許在限定範圍內進行操作,例如僅僅負責虛擬網路設定或文件系統管理、設定操作等。
|
||||
|
||||
最後,建議采用專用的服務器來執行 Docker 和相關的管理服務(例如管理服務比如 ssh 監控和程序監控、管理工具 nrpe、collectd 等)。其它的業務服務都放到容器中去執行。
|
||||
最後,建議采用專用的伺服器來執行 Docker 和相關的管理服務(例如管理服務比如 ssh 監控和程式監控、管理工具 nrpe、collectd 等)。其它的業務服務都放到容器中去執行。
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
## 內核能力機制
|
||||
|
||||
能力機制(Capability)是 Linux 內核一個強大的特性,可以提供細粒度的權限訪問控制。
|
||||
Linux 內核自 2.2 版本起就支持能力機制,它將權限劃分為更加細粒度的操作能力,既可以作用在程序上,也可以作用在文件上。
|
||||
Linux 內核自 2.2 版本起就支持能力機制,它將權限劃分為更加細粒度的操作能力,既可以作用在程式上,也可以作用在文件上。
|
||||
|
||||
例如,一個 Web 服務程序只需要綁定一個低於 1024 的端口的權限,並不需要 root 權限。那麽它只需要被授權 `net_bind_service` 能力即可。此外,還有很多其他的類似能力來避免程序獲取 root 權限。
|
||||
例如,一個 Web 服務程式只需要綁定一個低於 1024 的端口的權限,並不需要 root 權限。那麽它只需要被授權 `net_bind_service` 能力即可。此外,還有很多其他的類似能力來避免程式取得 root 權限。
|
||||
|
||||
默認情況下,Docker 啟動的容器被嚴格限制只允許使用內核的一部分能力。
|
||||
|
||||
使用能力機制對加強 Docker 容器的安全有很多好處。通常,在服務器上會執行一堆需要特權權限的程序,包括有 ssh、cron、syslogd、硬件管理工具模塊(例如負載模塊)、網路配置工具等等。容器跟這些程序是不同的,因為幾乎所有的特權程序都由容器以外的支持系統來進行管理。
|
||||
使用能力機制對加強 Docker 容器的安全有很多好處。通常,在伺服器上會執行一堆需要特權權限的程式,包括有 ssh、cron、syslogd、硬件管理工具模塊(例如負載模塊)、網路設定工具等等。容器跟這些程式是不同的,因為幾乎所有的特權程式都由容器以外的支持系統來進行管理。
|
||||
* ssh 訪問被主機上ssh服務來管理;
|
||||
* cron 通常應該作為使用者程序執行,權限交給使用它服務的應用來處理;
|
||||
* cron 通常應該作為使用者程式執行,權限交給使用它服務的應用來處理;
|
||||
* 日誌系統可由 Docker 或第三方服務管理;
|
||||
* 硬件管理無關緊要,容器中也就無需執行 udevd 以及類似服務;
|
||||
* 網路管理也都在主機上設置,除非特殊需求,容器不需要對網路進行配置。
|
||||
* 網路管理也都在主機上設置,除非特殊需求,容器不需要對網路進行設定。
|
||||
|
||||
從上面的例子可以看出,大部分情況下,容器並不需要“真正的” root 權限,容器只需要少數的能力即可。為了加強安全,容器可以禁用一些沒必要的權限。
|
||||
* 完全禁止任何 mount 操作;
|
||||
* 禁止直接訪問本地主機的套接字;
|
||||
* 禁止訪問一些文件系統的操作,比如建立新的設備、修改文件屬性等;
|
||||
* 禁止模塊加載。
|
||||
* 禁止模塊載入。
|
||||
|
||||
這樣,就算攻擊者在容器中取得了 root 權限,也不能獲得本地主機的較高權限,能進行的破壞也有限。
|
||||
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
## 內核名字空間
|
||||
Docker 容器和 LXC 容器很相似,所提供的安全特性也差不多。當用 `docker run` 啟動一個容器時,在後臺 Docker 為容器建立了一個獨立的名字空間和控制組集合。
|
||||
|
||||
名字空間提供了最基礎也是最直接的隔離,在容器中執行的程序不會被執行在主機上的程序和其它容器發現和作用。
|
||||
名字空間提供了最基礎也是最直接的隔離,在容器中執行的程式不會被執行在主機上的程式和其它容器發現和作用。
|
||||
|
||||
每個容器都有自己獨有的網路棧,意味著它們不能訪問其他容器的 sockets 或接口。不過,如果主機系統上做了相應的設置,容器可以像跟主機交互一樣的和其他容器交互。當指定公共端口或使用 links 來連接 2 個容器時,容器就可以相互通信了(可以根據配置來限制通信的策略)。
|
||||
每個容器都有自己獨有的網路棧,意味著它們不能訪問其他容器的 sockets 或接口。不過,如果主機系統上做了相應的設置,容器可以像跟主機交互一樣的和其他容器交互。當指定公共端口或使用 links 來連接 2 個容器時,容器就可以相互通信了(可以根據設定來限制通信的策略)。
|
||||
|
||||
從網路架構的角度來看,所有的容器透過本地主機的網橋接口相互通信,就像物理機器透過物理交換機通信一樣。
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
除了能力機制之外,還可以利用一些現有的安全機制來增強使用 Docker 的安全性,例如 TOMOYO, AppArmor, SELinux, GRSEC 等。
|
||||
|
||||
Docker 當前默認只啟用了能力機制。使用者可以采用多種方案來加強 Docker 主機的安全,例如:
|
||||
* 在內核中啟用 GRSEC 和 PAX,這將增加很多編譯和執行時的安全檢查;透過地址隨機化避免惡意探測等。並且,啟用該特性不需要 Docker 進行任何配置。
|
||||
* 在內核中啟用 GRSEC 和 PAX,這將增加很多編譯和執行時的安全檢查;透過地址隨機化避免惡意探測等。並且,啟用該特性不需要 Docker 進行任何設定。
|
||||
* 使用一些有增強安全特性的容器模板,比如帶 AppArmor 的模板和 Redhat 帶 SELinux 策略的模板。這些模板提供了額外的安全特性。
|
||||
* 使用者可以自定義訪問控制機制來定制安全策略。
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 總結
|
||||
總體來看,Docker 容器還是十分安全的,特別是在容器內不使用 root 權限來執行程序的話。
|
||||
總體來看,Docker 容器還是十分安全的,特別是在容器內不使用 root 權限來執行程式的話。
|
||||
|
||||
另外,使用者可以使用現有工具,比如 Apparmor, SELinux, GRSEC 來增強安全性;甚至自己在內核中實做更復雜的安全機制。
|
||||
|
||||
Reference in New Issue
Block a user