mirror of
https://github.com/yeasy/docker_practice.git
synced 2025-08-06 15:32:17 +00:00
replace '網絡' as '網路'
This commit is contained in:
@@ -7,12 +7,12 @@
|
||||
|
||||
為了加強對服務端的保護,Docker 的 REST API(客戶端用來跟服務端通信)在 0.5.2 之後使用本地的 Unix 套接字機制替代了原先綁定在 127.0.0.1 上的 TCP 套接字,因為後者容易遭受跨站腳本攻擊。現在用戶使用 Unix 權限檢查來加強套接字的訪問安全。
|
||||
|
||||
用戶仍可以利用 HTTP 提供 REST API 訪問。建議使用安全機制,確保只有可信的網絡或 VPN,或證書保護機制(例如受保護的 stunnel 和 ssl 認證)下的訪問可以進行。此外,還可以使用 HTTPS 和證書來加強保護。
|
||||
用戶仍可以利用 HTTP 提供 REST API 訪問。建議使用安全機制,確保只有可信的網路或 VPN,或證書保護機制(例如受保護的 stunnel 和 ssl 認證)下的訪問可以進行。此外,還可以使用 HTTPS 和證書來加強保護。
|
||||
|
||||
最近改進的 Linux 名字空間機制將可以實現使用非 root 用戶來執行全功能的容器。這將從根本上解決了容器和主機之間共享文件系統而引起的安全問題。
|
||||
|
||||
終極目標是改進 2 個重要的安全特性:
|
||||
* 將容器的 root 用戶映射到本地主機上的非 root 用戶,減輕容器和主機之間因權限提升而引起的安全問題;
|
||||
* 允許 Docker 服務端在非 root 權限下執行,利用安全可靠的子程序來代理執行需要特權權限的操作。這些子程序將只允許在限定範圍內進行操作,例如僅僅負責虛擬網絡設定或文件系統管理、配置操作等。
|
||||
* 允許 Docker 服務端在非 root 權限下執行,利用安全可靠的子程序來代理執行需要特權權限的操作。這些子程序將只允許在限定範圍內進行操作,例如僅僅負責虛擬網路設定或文件系統管理、配置操作等。
|
||||
|
||||
最後,建議采用專用的服務器來執行 Docker 和相關的管理服務(例如管理服務比如 ssh 監控和程序監控、管理工具 nrpe、collectd 等)。其它的業務服務都放到容器中去執行。
|
||||
|
@@ -7,12 +7,12 @@ Linux 內核自 2.2 版本起就支持能力機制,它將權限劃分為更加
|
||||
|
||||
默認情況下,Docker 啟動的容器被嚴格限制只允許使用內核的一部分能力。
|
||||
|
||||
使用能力機制對加強 Docker 容器的安全有很多好處。通常,在服務器上會執行一堆需要特權權限的程序,包括有 ssh、cron、syslogd、硬件管理工具模塊(例如負載模塊)、網絡配置工具等等。容器跟這些程序是不同的,因為幾乎所有的特權程序都由容器以外的支持系統來進行管理。
|
||||
使用能力機制對加強 Docker 容器的安全有很多好處。通常,在服務器上會執行一堆需要特權權限的程序,包括有 ssh、cron、syslogd、硬件管理工具模塊(例如負載模塊)、網路配置工具等等。容器跟這些程序是不同的,因為幾乎所有的特權程序都由容器以外的支持系統來進行管理。
|
||||
* ssh 訪問被主機上ssh服務來管理;
|
||||
* cron 通常應該作為用戶程序執行,權限交給使用它服務的應用來處理;
|
||||
* 日誌系統可由 Docker 或第三方服務管理;
|
||||
* 硬件管理無關緊要,容器中也就無需執行 udevd 以及類似服務;
|
||||
* 網絡管理也都在主機上設置,除非特殊需求,容器不需要對網絡進行配置。
|
||||
* 網路管理也都在主機上設置,除非特殊需求,容器不需要對網路進行配置。
|
||||
|
||||
從上面的例子可以看出,大部分情況下,容器並不需要“真正的” root 權限,容器只需要少數的能力即可。為了加強安全,容器可以禁用一些沒必要的權限。
|
||||
* 完全禁止任何 mount 操作;
|
||||
|
@@ -3,11 +3,11 @@ Docker 容器和 LXC 容器很相似,所提供的安全特性也差不多。
|
||||
|
||||
名字空間提供了最基礎也是最直接的隔離,在容器中執行的程序不會被執行在主機上的程序和其它容器發現和作用。
|
||||
|
||||
每個容器都有自己獨有的網絡棧,意味著它們不能訪問其他容器的 sockets 或接口。不過,如果主機系統上做了相應的設置,容器可以像跟主機交互一樣的和其他容器交互。當指定公共端口或使用 links 來連接 2 個容器時,容器就可以相互通信了(可以根據配置來限制通信的策略)。
|
||||
每個容器都有自己獨有的網路棧,意味著它們不能訪問其他容器的 sockets 或接口。不過,如果主機系統上做了相應的設置,容器可以像跟主機交互一樣的和其他容器交互。當指定公共端口或使用 links 來連接 2 個容器時,容器就可以相互通信了(可以根據配置來限制通信的策略)。
|
||||
|
||||
從網絡架構的角度來看,所有的容器通過本地主機的網橋接口相互通信,就像物理機器通過物理交換機通信一樣。
|
||||
從網路架構的角度來看,所有的容器通過本地主機的網橋接口相互通信,就像物理機器通過物理交換機通信一樣。
|
||||
|
||||
那麽,內核中實現名字空間和私有網絡的代碼是否足夠成熟?
|
||||
那麽,內核中實現名字空間和私有網路的代碼是否足夠成熟?
|
||||
|
||||
內核名字空間從 2.6.15 版本(2008 年 7 月發布)之後被引入,數年間,這些機制的可靠性在諸多大型生產系統中被實踐驗證。
|
||||
|
||||
|
@@ -6,4 +6,4 @@ Docker 當前默認只啟用了能力機制。用戶可以采用多種方案來
|
||||
* 使用一些有增強安全特性的容器模板,比如帶 AppArmor 的模板和 Redhat 帶 SELinux 策略的模板。這些模板提供了額外的安全特性。
|
||||
* 用戶可以自定義訪問控制機制來定制安全策略。
|
||||
|
||||
跟其它添加到 Docker 容器的第三方工具一樣(比如網絡拓撲和文件系統共享),有很多類似的機制,在不改變 Docker 內核情況下就可以加固現有的容器。
|
||||
跟其它添加到 Docker 容器的第三方工具一樣(比如網路拓撲和文件系統共享),有很多類似的機制,在不改變 Docker 內核情況下就可以加固現有的容器。
|
||||
|
Reference in New Issue
Block a user