Docker 架构介绍:docker安全最佳实践

简介

docker 赖以生存的“Secure by Default”,docker EE 默认的配置和策略提供基础雄厚的安全环境,所以,他们能够很是容易的修改来适应不一样组织的特殊需求。
docker 把重点放到了容器安全的三个关键领域:安全访问、安全内容、安全平台。这致使不只在Docker EE中内置了隔离和包容功能,并且还启用了开箱即用功能,Linux内核的攻击面积减小。Docker守护进程的控制功能获得了改进,管理员能够构建,发布并运行更安全的应用程序。html

你会学到什么

本文档概述了Docker EE的默认安全性以及进一步保护Universal Control Plane和Docker Trusted Registry的最佳作法。 Docker EE 2.0中引入的新功能,如Image Mirroring和Kubernetes也在探索中。linux

缩略语

UCP = Universal Control Plane
DTR = Docker Trusted Registry
RBAC = Role Based Access Control
CA = Certificate Authority
EE = Docker Enterprise Edition
HA = High Availability
BOM = Bill of Materials
CLI = Command Line Interface
CI = Continuous Integrationgit

引擎和节点安全

已经有几个资源涵盖了Docker引擎安全性的基础知识:github

限制节点的root访问

Docker EE使用来自主机的彻底独立的身份验证后端,提供明确的职责分离,Docker EE能够利用现有的LDAP / AD基础设施进行身份验证。它甚至使用RBAC标签来控制对镜像和运行容器等对象的访问,这意味着用户团队能够彻底访问正在运行的容器。 经过此访问,用户能够观看日志并在正在运行的容器内执行shell命令。 用户永远不须要登陆到主机。 限制有权访问主机的用户数量会减小攻击面。web

远程访问daemon

不要启用远程守护进程socket。 若是您必须打开它的引擎,那么老是使用证书来保护它。 使用通用控制平面时,不该该打开守护程序socket。 若是必须,请务必查看有关保护守护程序的socker说明。docker

Privileged 容器

尽量避免运行特权容器,运行特权容器可让容器访问全部主机的namespace(net\pid等等),这将给予容器控制主机的权限,经过保持容器和主机认证的独立性,确保您的基础设施安全。shell

容器UID管理

默认状况下,容器内的用户是root用户。 使用纵深防护模型,建议不是全部的容器都以root身份运行。 缓解这种状况的简单方法是在运行时使用–user声明。 该容器做为指定用户运行,实质上删除了根访问权限。
另请注意,容器内的文件的UID / GID组合与容器外部的文件是相同的,看下面的例子:一个容器以UID 10000和GID 10000运行。若是用户touch一个文件在/tmp/secret_file目录,则文件的UID / GID在容器内部和外部都是相同的,以下所示:json

root @ ~  docker run --rm -it -v /tmp:/tmp --user 10000:10000 alpine sh
/ $ whoami
whoami: unknown uid 10000
/ $ touch /tmp/secret_file
/ $ ls -asl /tmp/secret_file
     0 -rw-r--r--    1 10000    10000            0 Jan 26 13:48 /tmp/secret_file
/ $ exit
root @ ~  ls -asl /tmp/secret_file
0 -rw-r--r-- 1 10000 10000 0 Jan 26 08:48 /tmp/secret_file

开发人员在容器中应该尽量少的使用root权限,开发人员应该在他们的dockerfile中用USER声明建立运行容器的用户。后端

Seccomp

Seccomp(Secure Computing Mode的简写),是Linux内核的一项安全特性,用于限制给定进程的系统调用,这个特性出如今liunux内核2.6.12版本之后以及docker 1.10之后,当前的Docker Engine实现提供了一组默认的受限系统调用,而且还容许系统调用经过每一个容器的白名单或黑名单进行过滤(不一样的过滤器能够应用于运行在同一个引擎中的不一样容器),Seccomp配置文件在容器建立时应用,在容器运行之后不能更改。
开箱即用,Docker带有一个默认的Seccomp配置文件,对绝大多数用例都很是有效。 通常来讲,除非绝对必要,不然不建议应用自定义配置文件 有关构建自定义配置文件并应用它们的更多信息能够在Docker Seccomp文档中找到。
检查本身的系统是否支持seccomp,使用下面的命令:安全

cat /boot/config-uname -r | grep CONFIG_SECCOMP=

输入以下:
CONFIG_SECCOMP=y

AppArmor / SELinux

AppArmor和SELinux在使用配置文件方面与Seccomp相似,尽管他们在执行上有所不一样,AppArmor和SELinux使用的配置文件语言不一样,AppArmor仅适用于基于Debian的发行版,如Debian和Ubuntu。 SELinux可在Fedora / RHEL / CentOS / Oracle Linux上使用,而不是简单的系统调用和参数列表,都容许定义角色(一般是进程),动做(读取文件,网络操做)和目标(文件,IP,协议等)
要在Docker守护程序中启用SELinux,请修改/etc/docker/daemon.json并添加如下内容:

“selinux-enabled”: true

要检查SELinux是否启用:
docker info |grep -A 3 “Security Options”
输出以下:

vito@caas:~$ docker info |grep -A 3 "Security Options"
WARNING: No swap limit support
Security Options:
 apparmor
 seccomp
 Profile: default

AppArmor未应用于Docker守护进程。Apparmor配置文件须要在容器运行时应用:

docker run –rm -it –security-opt apparmor=docker-default hello-world

安装和设置AppArmor / SELinux一些很好的资源,例如:
http://www.tecmint.com/mandatory-access-control-with-selinux-or-apparmor-linux/
https://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html
底线是您应该始终将AppArmor或SELinux用于支持的操做系统。

Runtime Privilege 和 Linux Capabilities

https://success.docker.com/article/security-best-practices