引言
在当今云计算和容器化技能盛行的期间，Docker 作为一款领先的容器化平台，被广泛应用于各类应用的开辟、摆设与管理。然而，随着其应用范围的不断扩大，安全题目愈发受到关注。
Docker 是在 Linux操作体系层面上的假造化实现，运行在容器内的进程，跟运行在本地体系中的进程，本质上并无区别，不合适的安全计谋将大概给本地体系带来风险。因此Docker的安全性在生产环境中是十分关键的权衡因素。
Docker 容器的安全性，很大程度上其实依赖于Linux体系自身，因此在评估Docker的安全性时，主要考虑下面几个方面:
- Linux 内核的定名空间机制提供的容器隔离安全。
- Linux 控制组机制对容器资源的控制能力安全。
- Linux内核的能力机制所带来的操作权限安全
- Docker程序(特别是服务端)自己的抗攻击性
- 其他安全增强机制(包括AppArmor、SELinux等)对容器安全性的影响
1、定名空间隔离的安全
Docker 容器和LXC容器在实现上很相似，所提供的安全特性也根本一致。当用docker run启动一个容器时，Docker将在后台为容器创建一个独立的定名空间。
定名空间提供了最基础也是最直接的隔离，在容器中运行的进程不会被运行在本田主机上的进程和其他容器通过正常渠道发现和影响。
例如，通过定名空间机制，每个容器都有自己独有的网络栈，意味着它们不能访问其他容器的套接字(sockets)或接口。当然，容器默承认以与本田主机网络连通，如果主机体系上做了相应的互换设置，容器可以像跟主机交互一样的和其他容器交互。启动容器时，指定公共端口或使用连接体系，容器可以相互通信了(用户可以根据配置来限制通信的计谋)。
从网络架构的角度来看，全部的容器现实上是通过本田主机的网桥接口(Docker0)进行相互通信，就像物理呆板通过物理互换机通信一样。
那么，Linux内核中实现定名空间(特别是网络定名空间)的机制是否足够成熟呢?Linux内核从2.6.15版本(2008年7月发布)开始引人定名空间，至今履历了数年的演化和改进，并应用于诸多大型生产体系中。
现实上，定名空间的想法和设计提出的时间要更早，最初是OpenVz项目的重要特性OpenVz项目早在2005年就已经正式发布，其设计和实现更加成熟。
当然，与假造机方式相比，通过定名空间来实现的隔离并不是那么绝对。运行在容器中的应用可以直接访问体系内核和部分体系文件。因此，用户必须保证容器中应用是安全可信的(这跟保证运行在体系中的软件是可信的一个原理)，否则本地体系将大概受到威胁。现实上，Docker自1.30版本起对镜像管理引人了署名体系，用户可以通过署名来验证镜像的完整性和正确性。
2、控制组资源控制的安全
控制组（Control Groups，简称 cgroups）是 Linux 内核的另一个重要特性，它允许管理员对一组进程所使用的资源进行限制和统计。Docker 利用 cgroups 来实现对容器资源的精细控制，包括 CPU、内存、磁盘 I/O、网络带宽等。
控制组是 Linux容器机制中的别的一个关键组件，它负责实现资源的审计和限制。当用docker run启动一个容器时，Docker 将在后台为容器创建一个独立的控制组计谋聚集。控制组机制始于2006年，Linux内核从2.6.24版本开始被引人。
它提供了很多有用的特性;以及确保各个容器可以公平地分享主机的内存、CPU、磁盘IO等资源;当然，更重要的是，控制组确保了当发生在容器内的资源压力不会影响到本田主机体系和其他容器。
尽管控制组不负责隔离容器之间相互访问、处理数据和进程，但是它在防止拒绝服务攻击(DDoS)方面是必不可少的。尤其是在多用户的平台(好比公有或私有的Paas)上，控制组十分重要。例如，当某些应用容器出现非常的时间，可以保证本地体系和其他容器正常运行而不受影响。
3、内核能力机制
Linux 内核能力（Kernel Capabilities）是一种细粒度的权限管理机制，它冲破了传统的 “超级用户 - 普通用户” 二元权限模型。Docker 在运行容器时，可以根据现实需求为容器授予特定的内核能力，而不是让容器以 root 权限运行。
能力机制(Capability)是Linux内核一个强盛的特性，可以提供细粒度的权限访问控制。传统的 Unix体系对进程权限只有根权限(用户id为0，即为root用户)和非根权限(用户非root 用户)两种。
Linux内核自2.2版本起支持能力机制，它将权限分别为更加细粒度的操作能力，既可以作用在进程上，也可以作用在文件上。
例如，一个Web服务进程只需要绑定一个低于1024的端口的权限，并不需要完整的root权限。那么它只需要被授权netbind service能力即可。别的，还有很多其他的雷同能力来避免进程获取 root 权限。默认环境下，Docker启动的容器被严格限制只允许使用内核的一部分能力，包括chown、dac override、fowner、kill、setgid、setuid,setpcap、net bind service、 net raw、sys chroot、mknod、setfcap、audit write等。
使用能力机制对加强Docker容器的安全性有很多好处。通常，在服务器上会运行一堆需要特权权限的进程，包括有ssh、cron、syslogd、硬件管理工具模块(例如负载模块)、网络配置工具等等。容器跟这些进程是差别的，因为险些全部的特权进程都由容器以外的支持体系来进行管理。
- ssh 访问被宿主主机上的 ssh 服务来管理。
- cron 通常应该作为用户进程实行，权限交给使用它服务的应用来处理。
- 日记体系可由 Docker或第三方服务管理。
- 硬件管理无关紧急，容器中也就无需实行 udevd 以及雷同服务。
- 网络管理也都在主机上设置，除非特别需求，容器不需要对网络进行配置。
从上面的例子可以看出，大部分环境下，容器并不需要“真正的”root权限，容器只需要少数的能力即可。为了加强安全，容器可以禁用一些没须要的权限。
- 完全禁止任何文件挂载操作。
- 禁止直接访问本田主机的套接字。
- 禁止访问一些文件体系的操作，好比创建新的设备、修改文件属性等
- 禁止模块加载。
这样，就算攻击者在容器中取得了root权限，也不能获得本田主机的较高权限，能进行的破坏也有限。
不得当地分配了内核能力，会导致容器内应用获取破坏本地体系的权限。例如，早期的Docker版本曾经不得当的继承CAPDACREADSEARCH能力，导致容器内进程可以通过体系调用访问到本地体系的任意文件目次。
默认环境下，Docker采用“白名单”机制，禁用“必须功能”之外的其他权限。当然,用户也可以根据自身需求来为 Docker 容器启用额外的权限。
4、Docker服务端的防护
使用 Docker 容器的核心是 Docker 服务端。Docker 服务的运行如今还需要root 权限的支持，因此服务端安全性十分关键。
首先，必须确保只有可信的用户才可以访问到Docker服务。Docker允许用户在主机和容器间共享文件夹，同时不需要限制容器的访问权限，这就轻易让容器突破资源限制。
例如，恶意用户启动容器的时间将主机的根目次/映射到容器的host目次中，那么容器理论上就可以对主机的文件体系进行任意修改了。事实上，险些全部假造化体系都允许雷同的资源共享，而没法阻止恶意用户共享主机根文件体系到假造机体系。
这将会造成很严重的安全后果。因此，当提供容器创建服务时(例如通过一个web服务器)，要更加注意进行参数的安全查抄，防止恶意的用户用特定参数来创建一些破坏性的容器。为了加强对服务端的保护，Docker的RESTAPI(客户端用来跟服务端通信的接口)在0.5.2之后使用本地的Unix套接字机制替代了原先绑定在127.0.0.1上的TCP套接字，因为后者轻易遭受跨站脚本攻击。如今用户使用Unix权限查抄来加强套接字的访问安全。用户仍可以利用HTTP提供RESTAPI访问。发起使用安全机制，确保只有可信的网络或VPN 网络，或证书保护机制(例如受保护的stunnel和ssl认证)下的访间可以进行。别的，还可以使用HTTPS和证书来加强保护。
近来改进的Linux定名空间机制将可以实现使用非root用户来运行全功能的容器。这将从根本上解决了容器和主机之间共享文件体系而引起的安全题目。
如今，Docker自身改进安全防护的目标是实现以下两个重要安全特性:
- 将容器的root用户映射到本田主机上的非root用户，减轻容器和主机之间因权限提拔而引起的安全题目。
- 允许 Docker 服务端在非root权限下运行，利用安全可靠的子进程来署理实行需要特权权限的操作。这些子进程将只允许在限定范围内进行操作，例如仅仅负责假造网络设定或文件体系管理、配置操作等。
5、其他安全特性
除了能力机制之外，还可以利用一些现有的安全软件或机制来增强使用Docker的安全性，例如TOMOYO，AppArmor，SELinux，GRSEC 等。Docker 当前默认只启用了能力机制。用户可以选择启用更多的安全方案来加强Docker主机的安全，例如:
- 在内核中启用GRSEC和PAX，这将增加更多的编译和运行时的安全查抄;而且通过地址随机化机制来避免恶意探测等。启用该特性不需要Docker 进行任何配置。口使用一些有增强安全特性的容器模板，好比带AppArmor的模板和 Redhat带 SELinux计谋的模板。这些模板提供了额外的安全特性。
- 用户可以自界说更加严格的访问控制机制来定制安全计谋。别的，在将文件体系挂载到容器内部时间，可以通过配置只读(read-only)模式来避免容器内的应用通过文件体系破坏外部环境，特别是一些体系运行状态相干的目次，包括但不限于 /proc/sys、/proc/irg、/proc/bus等等。这样，容器内应用进程可以获取所需要的体系信息但无法对它们进行修改。
6、本章小结
总体来看，基于Linux上成熟的安全机制以及Apparmor,SELinux,GRSEC等安全机制Docker 容器还是比力安全的，特别是在容器内不使用root权限来运行进程的话。
但是任何技能层面实现的安全都需要用户公道的使用才能得到巩固，在使用Docker过程中，需要注意如下几方面:
- 在使用 Docker 容器运行应用的时间，一定要牢记容器自身所提供的隔离性其实并没有那么完善，需要加强对容器内应用的安全审查。容器即应用，保障应用安全的各种本领，都应该进行公道地利用。
- 采用专用的服务器来运行 Docker 服务端和相干的管理服务(例如管理服务好比ssh监控和进程监控、管理工具 nrpe、collectd 等)，并对该服务器启用最高级别的安全机制。而把其他的业务服务都放到容器中去运行。
- 将运行 Docker 容器的呆板分别为差别的组，互相信任的呆板放到同一个组内;组之间进行安全隔离;同时进行定期的安全查抄。
- 随着容器大规模地使用和集成，甚至组成容器集群。需要考虑在容器网络上进行必备的安全防护，避免诸如 DDOS、ARP攻击、规则表攻击等网络安全威胁，这也是生产环境需要关注的重要题目。
等待您能关注公众号原宏Cloud运维栈每天带你进步一点。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
