是。docker是是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，配置nfs权限是只读，nfs服务器安全战略:把敞开目录约束为只读权限能够在/etc/exports文裤和件中设定权限选项ro，一般需要把戚纯带NFS服务器对客高芦户敞开的任何目录或文件体系设置为只读拜。
做网站、网站建设介绍好的网站是理念、设计和技术的结合。创新互联公司拥有的网站设计理念、多方位的设计风格、经验丰富的设计团队。提供PC端+手机端网站建设，用营销思维进行网站设计、采用先进技术开源代码、注重用户体验与SEO基础，将技术与创意整合到网站之中，以契合客户的方式做到创意性的视觉化效果。
以Docker 容器的安全问题为例
(1) Docker 自身安全
Docker 作为一款容器李锋引擎，本身也会存在一些安全漏洞，CVE 目前已经记录了多项与 Docker 相关的安全漏洞，主要有权限提升、信息泄露等几类安全问题。
(2) 镜像安全
由于Docker 容器是基于镜像创建并启动，因此镜像的安全直接影响到容器的安全。具体影响镜像安全的总结如下。
镜像软件存在安全漏洞：由于容器需要安装基础的软件包，如果软件包存在漏洞，则可能会被不法分子利用并且侵入容器，影响其他容器或主机安全。
仓库漏洞：无论是Docker 官方的镜像仓库还是我们私有的镜像仓库，都有可能被攻击，然后篡改镜像，当我们使用镜像时，就可能成为攻击者的目标对象。
用户程序漏洞：用户自己构建的软件包可能存在漏洞或者被植入恶意脚本，这样会导致运行时提权影响其他容器或主机安全。
(3) Linux 内核隔离性不够
尽管目前Namespace 已经提供了非常多的资源隔离类型，但是仍有部分关键内容没有被完全隔离，其中包括一些系统的关键性目录（如 /sys、/proc 等），这些关键性的目录可能会泄露主机上一些关键性的信息，让攻击者利用这些信息对整个主机甚至云计算中心发起攻击。
而且仅仅依靠Namespace 的隔离是远远不够的，因为一旦内核的 Namespace 被突破，使用者就有可能直接提权获取到主机的超级权限，从而影响主机安全。
(4) 所有容器共享主机内核
由于同一宿主机上所有容器共享主机内核，所以攻击者可以利用一些特殊手段导致内核崩溃，进而导致主机宕机影响主机上其他服务。
既然容器有这么多安全上的问题，那么我们应该如何做才能够既享受到容器的便利性同时也可以保障容器安全呢？下面我带你来逐步了解下如何解决容器的安全问题。
如何解决容器的安全问题？
(1) Docker 自身安全性改进
事实上，Docker 从 2013 年诞生到现在，在安全性上面已经做了非常多的努力。目前 Docker 在默认配置和默认行为下是足够安全的。
Docker 自身是基于 Linux 的多种 Namespace 实现的，其中有一个很重要的 Namespace 叫作 User Namespace，User Namespace 主要是用来做容器内用户和主机的用户隔离的。在过去容器里的 root 用户就是主机上的 root 用户，如果容器受到攻击，或者容器本身含有恶意程序，在容器内就可以直接获取到主机 root 权限。Docker 从 1.10 版本开始，使用 User Namespace 做用户隔离，实现了容器中的 root 用户映射到主机上的非 root 用户，从而大大减轻了容器被突破的风险。
因此，我们尽可能地使用Docker 最新版本就可以得到更好的安全保障。
(2) 保障镜像安全
为保障镜像安全，我们可以在私有镜像仓库安装镜像安全扫描组件，对上传的镜像进行检查，通过与CVE 数据库迹拍对比，一旦发现有漏洞的镜像及时通知用户或阻止非安全镜像继续构建和分发。同时为了确保我姿扰羡们使用的镜像足够安全，在拉取镜像时，要确保只从受信任的镜像仓库拉取，并且与镜像仓库通信一定要使用 HTTPS 协议。
(3) 加强内核安全和管理
由于仅仅依赖内核的隔离可能会引发安全问题，因此我们对于内核的安全应该更加重视。可以从以下几个方面进行加强。
宿主机及时升级内核漏洞
宿主机内核应该尽量安装最新补丁，因为更新的内核补丁往往有着更好的安全性和稳定性。
使用Capabilities 划分权限
Capabilities 是 Linux 内核的概念，Linux 将系统权限分为了多个 Capabilities，它们都可以单独地开启或关闭，Capabilities 实现了系统更细粒度的访问控制。
容器和虚拟机在权限控制上还是有一些区别的，在虚拟机内我们可以赋予用户所有的权限，例如设置cron 定时任务、操作内核模块、配置网络等权限。而容器则需要针对每一项 Capabilities 更细粒度的去控制权限，例如：
cron 定时任务可以在容器内运行，设置定时任务的权限也仅限于容器内部；
由于容器是共享主机内核的，因此在容器内部一般不允许直接操作主机内核；
容器的网络管理在容器外部，这就意味着一般情况下，我们在容器内部是不需要执行ifconfig、route等命令的 。
由于容器可以按照需求逐项添加Capabilities 权限，因此在大多数情况下，容器并不需要主机的 root 权限，Docker 默认情况下也是不开启额外特权的。
最后，在执行docker run命令启动容器时，如非特殊可控情况，–privileged 参数不允许设置为 true，其他特殊权限可以使用 --cap-add 参数，根据使用场景适当添加相应的权限。
使用安全加固组件
Linux 的 SELinux、AppArmor、GRSecurity 组件都是 Docker 官方推荐的安全加固组件。下面我对这三个组件做简单介绍。
SELinux (Secure Enhanced Linux): 是 Linux 的一个内核安全模块，提供了安全访问的策略机制，通过设置 SELinux 策略可以实现某些进程允许访问某些文件。
AppArmor: 类似于 SELinux，也是一个 Linux 的内核安全模块，普通的访问控制仅能控制到用户的访问权限，而 AppArmor 可以控制到用户程序的访问权限。
GRSecurity: 是一个对内核的安全扩展，可通过智能访问控制，提供内存破坏防御，文件系统增强等多种防御形式。
这三个组件可以限制一个容器对主机的内核或其他资源的访问控制。目前，容器报告的一些安全漏洞中，很多都是通过对内核进行加强访问和隔离来实现的。
资源限制
在生产环境中，建议每个容器都添加相应的资源限制。下面给出一些执行docker run命令启动容器时可以传递的资源限制参数：
1 --cpus 限制 CPU 配额
2 -m, --memory 限制内存配额
3 --pids-limit 限制容器的 PID 个数
例如我想要启动一个1 核 2G 的容器，并且限制在容器内最多只能创建 1000 个 PID，启动命令如下：
1 $ docker run -it --cpus=1 -m=2048m --pids-limit=1000 busybox sh
推荐在生产环境中限制CPU、内存、PID 等资源，这样即便应用程序有漏洞，也不会导致主机的资源完全耗尽，最大限度降低安全风险。
(4) 使用安全容器
容器有着轻便快速启动的优点，虚拟机有着安全隔离的优点，有没有一种技术可以兼顾两者的优点，做到既轻量又安全呢？
答案是有，那就是安全容器。安全容器是相较于普通容器的，安全容器与普通容器的主要区别在于，安全容器中的每个容器都运行在一个单独的微型虚拟机中，拥有独立的操作系统和内核，并且有虚拟化层的安全隔离。
安全容器目前推荐的技术方案是Kata Containers，Kata Container 并不包含一个完整的操作系统，只有一个精简版的 Guest Kernel 运行着容器本身的应用，并且通过减少不必要的内存，尽量共享可以共享的内存来进一步减少内存的开销。另外，Kata Container 实现了 OCI 规范，可以直接使用 Docker 的镜像启动 Kata 容器，具有开销更小、秒级启动、安全隔离等许多优点。
Docker是Docker.Inc公司开源的一个基于轻量级虚拟化技术的容器引擎项目,整个项目基于Go语言开发，并遵从Apache 2.0协议。通过贺悄磨分层镜像标准化和内核虚拟化技术，Docker使得应用开发者和运维工程师可以以统一的方式跨平台发布应用，并且以几乎没有额外开销的情况下提供资源隔离的应用运行环境。由于众多新颖的特性以及项目本身的开放性，Docker在不到两禅斗年的时间里迅速获得诸多IT厂商的参与，其中更是包括Google、Microsoft、VMware等业界行业领导者。同时，Docker在开发者社区也是一石激起千层浪，许多如我之码农纷纷开始关注、学习和使用Docker，许多企业，尤其是互联网企业，也在不断加大对Docker的投入，大有掀起一场容器革命之势。
Docker镜像命名解析
镜像是Docker最核心的技术之一，也是应用发布的标准格式。无论你是用docker pull image，或者是在Dockerfile里面写FROM image，从Docker官方Registry下载镜像应该是Docker操作里面最频繁的动作之一了。那么在我们执行docker pull image时背后到底发生了什么呢？在回答这个问题前，我们需要先了解下docker镜像是如何命名的，这也是Docker里面比较容易令人混淆的一块概念：Registry，Repository, Tag and Image。
下面是在本地机器运行docker images的输出结果：
我们可以发现我们常说的“ubuntu”镜像其实不是一个镜像名称，而是代表了一个名为ubuntu的Repository，同时在这个Repository下面有一系列打了tag的Image，Image的标记是一个GUID，为了方便也可以通过Repository:tag来引用。
那么Registry又是什么呢？Registry存储镜像数据，并且提供拉取和上传镜像的功能。Registry中镜像是通过Repository来组织的，而每个Repository又包含了若干个Image。
Registry包含一个或多个Repository
Repository包含一个或多个Image
Image用GUID表示，有一个或多个Tag与之关联
那么在哪里指定Registry呢？让我们再拉取一个更完整命名的镜像吧：
上面我试图去拉取一个ubuntu镜像，并且指定了Registry为我本机搭建的私有Registry。下面是Docker CLI中pull命令的代码片段 (docker/api/client/command.go中的CmdPull函数)
在运行时，上面的taglessRemote变量会被传入localhost:5000/ubuntu。上面代码试图从taglessRemote变量中解析出Registry的地址，在我们的例子中，它是localhost:5000。
那我们回过头再来看看下面这个耳熟能详的pull命令背后的故事吧：运嫌
我们跟着上面的示例代码，进一步进入解析函数ResolveRepositoryName的定义代码片段(docker/registry/registry.go)
我们发现，Docker CLI会判断传入的taglessRemote参数的第一部分中是否包含’.’或者':’，如果存在则认为第一部分是Registry地址，否则会使用Docker官方默认的Registry（即index.docker.io其实这里是一个Index Server，和Registry的区别留在后面再去深究吧），即上面代码中高亮的部分。背后的故事还没有结束，如果你向DockerHub上传过镜像，应该记得你上传的镜像名称格式为user-name/repository:tag，这样用户Bob和用户Alice可以有相同名称的Repository，通过用户名前缀作为命名空间隔离，比如Bob/ubuntu和Alice/ubuntu。官方镜像是通过用户名library来区分的，具体代码片段如下(docker/api/client/command.go中的CmdPull函数)
我们回过头再去看Docker命令行中解析Tag的逻辑吧(docker/api/client/command.go中的CmdPull函数)：
代码会试着在用户输入的Image名称中找’ : ‘后面的tag,如果不存在，会使用默认的‘DEFAULTTAG’，即‘latest’。
也就是说在我们的例子里面，命令会被解析为下面这样（注意，下面的命令不能直接运行，因为Docker CLI不允许明确指定官方Registry地址）
配置Registry Mirror
Docker之所以这么吸引人，除了它的新颖的技术外，围绕官方Registry（Docker Hub）的生态圈也是相当吸引人眼球的地方。在Docker Hub上你可以很轻松下载到大量已经容器化好的应用镜像，即拉即用。这些镜像中，有些是Docker官方维护的，更多的是众多开发者自发上传分享的。而且你还可以在Docker Hub中绑定你的代码托管系统（目前支持Github和Bitbucket）配置自动生成镜像功能，这样Docker Hub会在你代码更新时自动生成对应的Docker镜像，是不是很方便？
不幸的是Docker Hub并没有在国内放服务器或者用国内的CDN，下载个镜像20分钟最起码，我等码农可耗不起这么长时间，老板正站在身后催着我们搬运代码呢。为了克服跨洋网络延迟，一般有两个解决方案：一是使用私有Registry，另外是使用Registry Mirror，我们下面一一展开聊聊.
方案一就是搭建或者使用现有的私有Registry，通过定期和Docker Hub同步热门的镜像，私有Registry上保存了一些镜像的副本，然后大家可以通过docker pull private-registry点抗 /user-name/ubuntu:latest，从这个私有Registry上拉取镜像。因为这个方案需要定期同步Docker Hub镜像，因此它比较适合于使用的镜像相对稳定，或者都是私有镜像的场景。而且用户需要显式的映射官方镜像名称到私有镜像名称，私有Registry更多被大家应用在企业内部场景。私有Registry部署也很方便，可以直接在Docker Hub上下载Registry镜像，即拉即用，具体部署可以参考官方文档。
方案二是使用Registry Mirror，它的原理类似于缓存，如果镜像在Mirror中命中则直接返回给客户端，否则从存放镜像的Registry上拉取并自动缓存在Mirror中。最酷的是，是否使用Mirror对Docker使用者来讲是透明的，也就是说在配置Mirror以后，大家可以仍然输入docker pull ubuntu来拉取Docker Hub镜像，除了速度变快了，和以前没有任何区别。
了以更便捷的方式对接Docker Hub生态圈，使用Registry Mirror自然成为我的首选。接下来我就和大家一起看看Docker使用Mirror来拉取镜像的过程。下面的例子，我使用的是由DaoCloud提供的Registry Mirror服务，在申请开通Mirror服务后你会得到一个Mirror地址，然后我们要做的就是把这个地址配置在Docker Server启动脚本中，重启Docker服务后Mirror配置就生效了（如何获得Mirror服务可以参考本篇文章的附录）
Ubuntu下配置Docker Registry Mirror的命令如下：
sudo echo “DOCKER_OPTS=\”\$DOCKER_OPTS –registry-mirror= -d\”” /etc/default/docker
sudo service docker restart
如果你是用的Boot2Docker，配置命令为：
# 进入Boot2Docker Start Shell，并执行
sudo su
echo “EXTRA_ARGS=\”–registry-mirror=\”” /var/lib/boot2docker/profile
exit
# 重启Boot2Docker
配置好Registry Mirror后，就可以拉取Docker镜像了，经我测试，使用DaoCloud的Mirror后，拉取常见镜像的速度可以达到1.5M左右，具体速度在你的网络环境可能会略有不同。
我们来看看配置了Registry Mirror后，Docker拉取镜像的过程吧。首先是CLI拉取镜像命令代码片段(docker/api/client/command.go中的CmdPull函数)
首先，Docker CLI会试图获得授权，在我们的例子中会向请求认证，认证完成后，认证服务器会返回一个对应的Token。注意，这里用户认证与配置的Registry Mirror完全无关，这样我们就不用担心使用Mirror的安全问题了。接着Docker CLI会调用Docker Server（即Docker daemon程序）的创建镜像命令，Docker Server随之会执行具体的拉取镜像动作，代码片段如下(docker/graph/pull.go的pullRepository函数)
从代码中可以发现，如果配置了Registry Mirror，Docker Server会首先从Mirror中拉取镜像，如果Mirror拉取失败会退而求其次从镜像中指定的Registry拉取。大家又可以松口气了，就算配置的Registry Mirror失效，也不会影响用户拉取镜像，只不过速度就。。。
镜像拉下来后，就可以运行容器了
