translate security into traditional chinese

security/README.md

@@ -1,5 +1,5 @@
 # 安全
-评估 Docker 的安全性时，主要考虑三个方面:
-* 由内核的名字空间和控制组机制提供的容器内在安全
-* Docker程序（特别是服务端）本身的抗攻击性
-* 内核安全性的加强机制对容器安全性的影响
+評估 Docker 的安全性時，主要考慮三個方面:
+* 由內核的名字空間和控制組機制提供的容器內在安全
+* Docker程序（特別是服務端）本身的抗攻擊性
+* 內核安全性的加強機制對容器安全性的影響

security/control_group.md

@@ -1,8 +1,8 @@
-## 控制组
-控制组是 Linux 容器机制的另外一个关键组件，负责实现资源的审计和限制。
+## 控制組
+控制組是 Linux 容器機制的另外一個關鍵組件，負責實現資源的審計和限制。
 
-它提供了很多有用的特性；以及确保各个容器可以公平地分享主机的内存、CPU、磁盘 IO 等资源；当然，更重要的是，控制组确保了当容器内的资源使用产生压力时不会连累主机系统。
+它提供了很多有用的特性；以及確保各個容器可以公平地分享主機的內存、CPU、磁盤 IO 等資源；當然，更重要的是，控制組確保了當容器內的資源使用產生壓力時不會連累主機系統。
 
-尽管控制组不负责隔离容器之间相互访问、处理数据和进程，它在防止拒绝服务（DDOS）攻击方面是必不可少的。尤其是在多用户的平台（比如公有或私有的 PaaS）上，控制组十分重要。例如，当某些应用程序表现异常的时候，可以保证一致地正常运行和性能。
+盡管控制組不負責隔離容器之間相互訪問、處理數據和進程，它在防止拒絕服務（DDOS）攻擊方面是必不可少的。尤其是在多用戶的平臺（比如公有或私有的 PaaS）上，控制組十分重要。例如，當某些應用程序表現異常的時候，可以保證一致地正常運行和性能。
 
-控制组机制始于 2006 年，内核从 2.6.24 版本开始被引入。
+控制組機制始於 2006 年，內核從 2.6.24 版本開始被引入。

security/daemon_sec.md

@@ -1,18 +1,18 @@
-## Docker服务端的防护
-运行一个容器或应用程序的核心是通过 Docker 服务端。Docker 服务的运行目前需要 root 权限，因此其安全性十分关键。
+## Docker服務端的防護
+運行一個容器或應用程序的核心是通過 Docker 服務端。Docker 服務的運行目前需要 root 權限，因此其安全性十分關鍵。
 
-首先，确保只有可信的用户才可以访问 Docker 服务。Docker 允许用户在主机和容器间共享文件夹，同时不需要限制容器的访问权限，这就容易让容器突破资源限制。例如，恶意用户启动容器的时候将主机的根目录`/`映射到容器的 `/host` 目录中，那么容器理论上就可以对主机的文件系统进行任意修改了。这听起来很疯狂？但是事实上几乎所有虚拟化系统都允许类似的资源共享，而没法禁止用户共享主机根文件系统到虚拟机系统。
+首先，確保只有可信的用戶才可以訪問 Docker 服務。Docker 允許用戶在主機和容器間共享文件夾，同時不需要限制容器的訪問權限，這就容易讓容器突破資源限制。例如，惡意用戶啟動容器的時候將主機的根目錄`/`映射到容器的 `/host` 目錄中，那麽容器理論上就可以對主機的文件系統進行任意修改了。這聽起來很瘋狂？但是事實上幾乎所有虛擬化系統都允許類似的資源共享，而沒法禁止用戶共享主機根文件系統到虛擬機系統。
 
-这将会造成很严重的安全后果。因此，当提供容器创建服务时（例如通过一个 web 服务器），要更加注意进行参数的安全检查，防止恶意的用户用特定参数来创建一些破坏性的容器
+這將會造成很嚴重的安全後果。因此，當提供容器創建服務時（例如通過一個 web 服務器），要更加註意進行參數的安全檢查，防止惡意的用戶用特定參數來創建一些破壞性的容器
 
-为了加强对服务端的保护，Docker 的 REST API（客户端用来跟服务端通信）在 0.5.2 之后使用本地的 Unix 套接字机制替代了原先绑定在 127.0.0.1 上的 TCP 套接字，因为后者容易遭受跨站脚本攻击。现在用户使用 Unix 权限检查来加强套接字的访问安全。
+為了加強對服務端的保護，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 用户来运行全功能的容器。这将从根本上解决了容器和主机之间共享文件系统而引起的安全问题。
+最近改進的 Linux 名字空間機制將可以實現使用非 root 用戶來運行全功能的容器。這將從根本上解決了容器和主機之間共享文件系統而引起的安全問題。
 
-终极目标是改进 2 个重要的安全特性：
-* 将容器的 root 用户映射到本地主机上的非 root 用户，减轻容器和主机之间因权限提升而引起的安全问题；
-* 允许 Docker 服务端在非 root 权限下运行，利用安全可靠的子进程来代理执行需要特权权限的操作。这些子进程将只允许在限定范围内进行操作，例如仅仅负责虚拟网络设定或文件系统管理、配置操作等。
+終極目標是改進 2 個重要的安全特性：
+* 將容器的 root 用戶映射到本地主機上的非 root 用戶，減輕容器和主機之間因權限提升而引起的安全問題；
+* 允許 Docker 服務端在非 root 權限下運行，利用安全可靠的子進程來代理執行需要特權權限的操作。這些子進程將只允許在限定範圍內進行操作，例如僅僅負責虛擬網絡設定或文件系統管理、配置操作等。
 
-最后，建议采用专用的服务器来运行 Docker 和相关的管理服务（例如管理服务比如 ssh 监控和进程监控、管理工具 nrpe、collectd 等）。其它的业务服务都放到容器中去运行。
+最後，建議采用專用的服務器來運行 Docker 和相關的管理服務（例如管理服務比如 ssh 監控和進程監控、管理工具 nrpe、collectd 等）。其它的業務服務都放到容器中去運行。

security/kernel_capability.md

@@ -1,26 +1,26 @@
-## 内核能力机制
+## 內核能力機制
 
-能力机制（Capability）是 Linux 内核一个强大的特性，可以提供细粒度的权限访问控制。
-Linux 内核自 2.2 版本起就支持能力机制，它将权限划分为更加细粒度的操作能力，既可以作用在进程上，也可以作用在文件上。
+能力機制（Capability）是 Linux 內核一個強大的特性，可以提供細粒度的權限訪問控制。
+Linux 內核自 2.2 版本起就支持能力機制，它將權限劃分為更加細粒度的操作能力，既可以作用在進程上，也可以作用在文件上。
 
-例如，一个 Web 服务进程只需要绑定一个低于 1024 的端口的权限，并不需要 root 权限。那么它只需要被授权 `net_bind_service` 能力即可。此外，还有很多其他的类似能力来避免进程获取 root 权限。
+例如，一個 Web 服務進程只需要綁定一個低於 1024 的端口的權限，並不需要 root 權限。那麽它只需要被授權 `net_bind_service` 能力即可。此外，還有很多其他的類似能力來避免進程獲取 root 權限。
 
-默认情况下，Docker 启动的容器被严格限制只允许使用内核的一部分能力。
+默認情況下，Docker 啟動的容器被嚴格限制只允許使用內核的一部分能力。
 
-使用能力机制对加强 Docker 容器的安全有很多好处。通常，在服务器上会运行一堆需要特权权限的进程，包括有 ssh、cron、syslogd、硬件管理工具模块（例如负载模块）、网络配置工具等等。容器跟这些进程是不同的，因为几乎所有的特权进程都由容器以外的支持系统来进行管理。
-* ssh 访问被主机上ssh服务来管理；
-* cron 通常应该作为用户进程执行，权限交给使用它服务的应用来处理；
-* 日志系统可由 Docker 或第三方服务管理；
-* 硬件管理无关紧要，容器中也就无需执行 udevd 以及类似服务；
-* 网络管理也都在主机上设置，除非特殊需求，容器不需要对网络进行配置。
+使用能力機制對加強 Docker 容器的安全有很多好處。通常，在服務器上會運行一堆需要特權權限的進程，包括有 ssh、cron、syslogd、硬件管理工具模塊（例如負載模塊）、網絡配置工具等等。容器跟這些進程是不同的，因為幾乎所有的特權進程都由容器以外的支持系統來進行管理。
+* ssh 訪問被主機上ssh服務來管理；
+* cron 通常應該作為用戶進程執行，權限交給使用它服務的應用來處理；
+* 日誌系統可由 Docker 或第三方服務管理；
+* 硬件管理無關緊要，容器中也就無需執行 udevd 以及類似服務；
+* 網絡管理也都在主機上設置，除非特殊需求，容器不需要對網絡進行配置。
 
-从上面的例子可以看出，大部分情况下，容器并不需要“真正的” root 权限，容器只需要少数的能力即可。为了加强安全，容器可以禁用一些没必要的权限。
+從上面的例子可以看出，大部分情況下，容器並不需要“真正的” root 權限，容器只需要少數的能力即可。為了加強安全，容器可以禁用一些沒必要的權限。
 * 完全禁止任何 mount 操作；
-* 禁止直接访问本地主机的套接字；
-* 禁止访问一些文件系统的操作，比如创建新的设备、修改文件属性等；
-* 禁止模块加载。
+* 禁止直接訪問本地主機的套接字；
+* 禁止訪問一些文件系統的操作，比如創建新的設備、修改文件屬性等；
+* 禁止模塊加載。
 
-这样，就算攻击者在容器中取得了 root 权限，也不能获得本地主机的较高权限，能进行的破坏也有限。
+這樣，就算攻擊者在容器中取得了 root 權限，也不能獲得本地主機的較高權限，能進行的破壞也有限。
 
-默认情况下，Docker采用 [白名单](https://github.com/docker/docker/blob/master/daemon/execdriver/native/template/default_template.go) 机制，禁用 [必需功能](https://github.com/docker/docker/blob/master/daemon/execdriver/native/template/default_template.go) 之外的其它权限。
-当然，用户也可以根据自身需求来为 Docker 容器启用额外的权限。
+默認情況下，Docker采用 [白名單](https://github.com/docker/docker/blob/master/daemon/execdriver/native/template/default_template.go) 機制，禁用 [必需功能](https://github.com/docker/docker/blob/master/daemon/execdriver/native/template/default_template.go) 之外的其它權限。
+當然，用戶也可以根據自身需求來為 Docker 容器啟用額外的權限。

security/kernel_ns.md

@@ -1,15 +1,15 @@
-## 内核名字空间
-Docker 容器和 LXC 容器很相似，所提供的安全特性也差不多。当用 `docker run` 启动一个容器时，在后台 Docker 为容器创建了一个独立的名字空间和控制组集合。
+## 內核名字空間
+Docker 容器和 LXC 容器很相似，所提供的安全特性也差不多。當用 `docker run` 啟動一個容器時，在後臺 Docker 為容器創建了一個獨立的名字空間和控制組集合。
 
-名字空间提供了最基础也是最直接的隔离，在容器中运行的进程不会被运行在主机上的进程和其它容器发现和作用。
+名字空間提供了最基礎也是最直接的隔離，在容器中運行的進程不會被運行在主機上的進程和其它容器發現和作用。
 
-每个容器都有自己独有的网络栈，意味着它们不能访问其他容器的 sockets 或接口。不过，如果主机系统上做了相应的设置，容器可以像跟主机交互一样的和其他容器交互。当指定公共端口或使用 links 来连接 2 个容器时，容器就可以相互通信了（可以根据配置来限制通信的策略）。
+每個容器都有自己獨有的網絡棧，意味著它們不能訪問其他容器的 sockets 或接口。不過，如果主機系統上做了相應的設置，容器可以像跟主機交互一樣的和其他容器交互。當指定公共端口或使用 links 來連接 2 個容器時，容器就可以相互通信了（可以根據配置來限制通信的策略）。
 
-从网络架构的角度来看，所有的容器通过本地主机的网桥接口相互通信，就像物理机器通过物理交换机通信一样。
+從網絡架構的角度來看，所有的容器通過本地主機的網橋接口相互通信，就像物理機器通過物理交換機通信一樣。
 
-那么，内核中实现名字空间和私有网络的代码是否足够成熟？
+那麽，內核中實現名字空間和私有網絡的代碼是否足夠成熟？
 
-内核名字空间从 2.6.15 版本（2008 年 7 月发布）之后被引入，数年间，这些机制的可靠性在诸多大型生产系统中被实践验证。
+內核名字空間從 2.6.15 版本（2008 年 7 月發布）之後被引入，數年間，這些機制的可靠性在諸多大型生產系統中被實踐驗證。
 
-实际上，名字空间的想法和设计提出的时间要更早，最初是为了在内核中引入一种机制来实现 [OpenVZ](http://en.wikipedia.org/wiki/OpenVZ) 的特性。
-而 OpenVZ 项目早在 2005 年就发布了，其设计和实现都已经十分成熟。
+實際上，名字空間的想法和設計提出的時間要更早，最初是為了在內核中引入一種機制來實現 [OpenVZ](http://en.wikipedia.org/wiki/OpenVZ) 的特性。
+而 OpenVZ 項目早在 2005 年就發布了，其設計和實現都已經十分成熟。

security/other_feature.md

@@ -1,9 +1,9 @@
 ## 其它安全特性
-除了能力机制之外，还可以利用一些现有的安全机制来增强使用 Docker 的安全性，例如 TOMOYO, AppArmor, SELinux, GRSEC 等。
+除了能力機制之外，還可以利用一些現有的安全機制來增強使用 Docker 的安全性，例如 TOMOYO, AppArmor, SELinux, GRSEC 等。
 
-Docker 当前默认只启用了能力机制。用户可以采用多种方案来加强 Docker 主机的安全，例如：
-* 在内核中启用 GRSEC 和 PAX，这将增加很多编译和运行时的安全检查；通过地址随机化避免恶意探测等。并且，启用该特性不需要 Docker 进行任何配置。
-* 使用一些有增强安全特性的容器模板，比如带 AppArmor 的模板和 Redhat 带 SELinux 策略的模板。这些模板提供了额外的安全特性。
-* 用户可以自定义访问控制机制来定制安全策略。
+Docker 當前默認只啟用了能力機制。用戶可以采用多種方案來加強 Docker 主機的安全，例如：
+* 在內核中啟用 GRSEC 和 PAX，這將增加很多編譯和運行時的安全檢查；通過地址隨機化避免惡意探測等。並且，啟用該特性不需要 Docker 進行任何配置。
+* 使用一些有增強安全特性的容器模板，比如帶 AppArmor 的模板和 Redhat 帶 SELinux 策略的模板。這些模板提供了額外的安全特性。
+* 用戶可以自定義訪問控制機制來定制安全策略。
 
-跟其它添加到 Docker 容器的第三方工具一样（比如网络拓扑和文件系统共享），有很多类似的机制，在不改变 Docker 内核情况下就可以加固现有的容器。
+跟其它添加到 Docker 容器的第三方工具一樣（比如網絡拓撲和文件系統共享），有很多類似的機制，在不改變 Docker 內核情況下就可以加固現有的容器。

security/summary.md

@@ -1,4 +1,4 @@
-## 总结
-总体来看，Docker 容器还是十分安全的，特别是在容器内不使用 root 权限来运行进程的话。
+## 總結
+總體來看，Docker 容器還是十分安全的，特別是在容器內不使用 root 權限來運行進程的話。
 
-另外，用户可以使用现有工具，比如 Apparmor, SELinux, GRSEC 来增强安全性；甚至自己在内核中实现更复杂的安全机制。
+另外，用戶可以使用現有工具，比如 Apparmor, SELinux, GRSEC 來增強安全性；甚至自己在內核中實現更復雜的安全機制。