docker_practice/security/kernel_ns.md
Baohua Yang 71f0f50f27 Merge branch 'master' of https://github.com/cxjava/docker_practice into cxjava-master
Conflicts:
	security/control_group.md
	security/daemon_sec.md
	security/kernel_capability.md
	security/kernel_ns.md
2014-09-22 10:04:22 +08:00

16 lines
1.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容器和LXC容器很相似所提供的安全特性也差不多。当用`docker run`启动一个容器时在后台Docker为容器创建了一个独立的名字空间和控制组集合。
名字空间提供了最基础也是最直接的隔离,在容器中运行的进程不会被运行在主机上的进程和其它容器发现和作用。
每个容器都有自己独有的网络栈意味着它们不能访问其他容器的sockets或接口。不过如果主机系统上做了相应的设置容器可以像跟主机交互一样的和其他容器交互。当指定公共端口或使用links来连接2个容器时容器就可以相互通信了可以根据配置来限制通信的策略
从网络架构的角度来看,所有的容器通过本地主机的网桥接口相互通信,就像物理机器通过物理交换机通信一样。
那么,内核中实现名字空间和私有网络的代码是否足够成熟?
内核名字空间从2.6.15版本2008年七月发布之后被引入数年间这些机制的可靠性在诸多大型生产系统中被实践验证。
实际上,名字空间的想法和设计提出的时间要更早,最初是为了在内核中引入一种机制来实现[OpenVZ](http://en.wikipedia.org/wiki/OpenVZ)的特性。
而OpenVZ项目早在2005年就发布了其设计和实现都已经十分成熟。