Docker 架构介绍：docker安全最佳实践 - 好文

简介

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

你会学到什么

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

缩略语

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 Integration

引擎和节点安全

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

* Docker Security Documentation：涵盖了基础知识，如命名空间和控制组，Docker守护进程的攻击面以及其他内核安全功能。（
https://docs.docker.com/engine/security/security/
<https://docs.docker.com/engine/security/security/>）
* CIS Docker Community Edition Benchmark：涵盖了Docker Engine中各种与安全相关的选项。 Docker
EE很有用。（https://www.cisecurity.org/benchmark/docker/
<https://www.cisecurity.org/benchmark/docker/>）
* Docker Bench Security：一个脚本，用于根据CIS基准检查Docker引擎的配置。（
https://github.com/docker/docker-bench-security
<https://github.com/docker/docker-bench-security>）
限制节点的root访问

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

远程访问daemon

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

Privileged 容器

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

容器UID管理

默认情况下，容器内的用户是root用户。使用纵深防御模型，建议不是所有的容器都以root身份运行。缓解这种情况的简单方法是在运行时使用–user声明。
该容器作为指定用户运行，实质上删除了根访问权限。
另请注意，容器内的文件的UID / GID组合与容器外部的文件是相同的，看下面的例子：一个容器以UID 10000和GID
10000运行。如果用户touch一个文件在/tmp/secret_file目录，则文件的UID / GID在容器内部和外部都是相同的，如下所示：
root @ ~ docker run --rm -it -v /tmp:/tmp --user 10000:10000 alpine sh / $
whoami whoami: unknown uid10000 / $ touch /tmp/secret_file / $ ls -asl
/tmp/secret_file0 -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/

<http://www.tecmint.com/mandatory-access-control-with-selinux-or-apparmor-linux/>
https://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html
<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
<https://success.docker.com/article/security-best-practices>

热门工具换一换