Docker Engine 安全
审查 Docker 安全时需要考虑四个主要领域：
- 内核本身及其对命名空间和 cgroups 的支持的固有安全性
- Docker 守护进程自身的攻击面
- 容器配置文件中的漏洞，无论是默认配置，还是用户自定义配置
- 内核的“加固”安全功能及其与容器的交互方式
内核命名空间
Docker 容器与 LXC 容器非常相似，具有类似的安全特性。当你使用 docker run 启动容器时，Docker 在后台为容器创建一组命名空间和控制组。
命名空间提供了第一层也是最直接的隔离形式。在容器内运行的进程无法看到，更无法影响在另一个容器或主机系统中运行的进程。
每个容器还获得自己的网络栈，这意味着容器无法获得对另一个容器的套接字或接口的特权访问。当然，如果主机系统相应设置，容器可以通过各自的网络接口相互交互——就像它们可以与外部主机交互一样。当你为容器指定公开端口或使用 链接 时，IP 流量允许在容器之间传输。它们可以相互 ping 通，发送/接收 UDP 数据包，并建立 TCP 连接，但如有必要，这些可以被限制。从网络架构的角度来看，给定 Docker 主机上的所有容器都位于桥接接口上。这意味着它们就像通过公共以太网交换机连接的物理机器；仅此而已。
提供内核命名空间和私有网络的代码有多成熟？内核命名空间在 内核版本 2.6.15 和 2.6.26 之间 引入。这意味着自 2008 年 7 月（2.6.26 发布日期）以来，命名空间代码已在大量生产系统上得到测试和审查。不仅如此：命名空间代码的设计和灵感甚至更早。命名空间实际上是尝试以一种可以合并到主流内核中的方式重新实现 OpenVZ 的特性。而 OpenVZ 最初于 2005 年发布，因此其设计和实现都相当成熟。
控制组
控制组（Control Groups）是 Linux 容器的另一个关键组件。它们实现资源会计和限制。它们提供许多有用的指标，但也有助于确保每个容器获得公平的内存、CPU、磁盘 I/O 分配；更重要的是，防止单个容器通过耗尽这些资源之一使系统崩溃。
因此，虽然它们在防止一个容器访问或影响另一个容器的数据和进程方面不起作用，但它们对于抵御某些拒绝服务攻击至关重要。它们在多租户平台（如公共和私有 PaaS）上尤其重要，以保证即使某些应用程序开始行为异常，也能维持一致的正常运行时间（和性能）。
控制组也已经存在一段时间了：代码始于 2006 年，最初合并到内核 2.6.24 中。
Docker 守护进程攻击面
使用 Docker 运行容器（和应用程序）意味着需要运行 Docker 守护进程。此守护进程需要 root 权限，除非你选择 无根模式，因此你应该了解一些重要细节。
首先，只有受信任的用户才应被允许控制你的 Docker 守护进程。这是 Docker 某些强大功能的直接后果。具体来说，Docker 允许你在 Docker 主机和客户容器之间共享目录；并且它允许你这样做，而不限制容器的访问权限。这意味着你可以启动一个容器，其中 /host 目录是主机上的 / 目录；容器可以不受限制地修改主机文件系统。这类似于虚拟化系统允许文件系统资源共享的方式。没有任何东西阻止你与虚拟机共享根文件系统（甚至根块设备）。
这具有重要的安全影响：例如，如果你通过 Web 服务器使用 API 来配置容器，你应该比平常更加小心参数检查，以确保恶意用户无法传递精心制作的参数，导致 Docker 创建任意容器。
出于这个原因，Docker 0.5.2 中 REST API 端点（Docker CLI 用于与 Docker 守护进程通信）发生了变化，现在使用 Unix 套接字而不是绑定在 127.0.0.1 上的 TCP 套接字（后者如果恰好在本地机器上直接运行 Docker（在 VM 之外）时容易受到跨站请求伪造攻击）。然后你可以使用传统的 Unix 权限检查来限制对控制套接字的访问。
如果你明确决定这样做，也可以通过 HTTP 暴露 REST API。但是，如果你这样做，请注意上述安全影响。请注意，即使你有防火墙限制从网络中的其他主机访问 REST API 端点，该端点仍然可能从容器中访问，并且很容易导致权限提升。因此，使用 HTTPS 和证书 保护 API 端点是强制性的。不允许通过 HTTP 暴露守护进程 API 而不使用 TLS，这样的配置会导致守护进程在启动早期失败，请参阅 未经认证的 TCP 连接。还建议确保它只能从受信任的网络或 VPN 访问。
如果你更喜欢 SSH 而非 TLS，也可以使用 DOCKER_HOST=ssh://USER@HOST 或 ssh -L /path/to/docker.sock:/var/run/docker.sock。
守护进程也可能容易受到其他输入的攻击，比如从磁盘使用 docker load 加载镜像，或从网络使用 docker pull 加载镜像。从 Docker 1.3.2 开始，镜像现在在 Linux/Unix 平台上的 chroot 子进程中提取，这是迈向权限分离的更广泛努力的第一步。从 Docker 1.10.0 开始，所有镜像都通过其内容的加密校验和存储和访问，限制了攻击者与现有镜像发生冲突的可能性。
最后，如果你在服务器上运行 Docker，建议在服务器上仅运行 Docker，并将所有其他服务移至由 Docker 控制的容器内。当然，保留你喜欢的管理工具（可能至少包括 SSH 服务器）以及现有的监控/监督进程（如 NRPE 和 collectd）是可以的。
Linux 内核能力
默认情况下，Docker 以受限的能力集启动容器。这意味着什么？
能力将二元的“root/non-root”二分法转变为细粒度的访问控制系统。只需要绑定到 1024 以下端口的进程（如 Web 服务器）不需要以 root 身份运行：它们只需要被授予 net_bind_service 能力即可。还有许多其他能力，涵盖了几乎所有通常需要 root 权限的特定领域。这对容器安全意义重大。
典型服务器运行多个进程作为 root，包括 SSH 守护进程、cron 守护进程、日志守护进程、内核模块、网络配置工具等。容器不同，因为几乎所有这些任务都由容器周围的基础设施处理：
- SSH 访问通常由 Docker 主机上运行的单个服务器管理
cron（如有必要）应该作为用户进程运行，专为需要其调度服务的应用程序定制，而不是作为全平台设施- 日志管理通常也交给 Docker，或第三方服务如 Loggly 或 Splunk
- 硬件管理无关紧要，意味着你永远不需要在容器内运行
udevd或等效守护进程 - 网络管理发生在容器外部，最大程度地实施关注点分离，意味着容器永远不需要执行
ifconfig、route或 ip 命令（当然，除非容器被特别设计为表现得像路由器或防火墙）
这意味着在大多数情况下，容器根本不需要“真正的”root 权限。因此，容器可以以减少的能力集运行；这意味着容器内的“root”权限远小于真正的“root”。例如，可以：
- 拒绝所有“mount”操作
- 拒绝对原始套接字的访问（防止数据包欺骗）
- 拒绝对某些文件系统操作的访问，如创建新设备节点、更改文件所有者或更改属性（包括不可变标志）
- 拒绝模块加载
这意味着即使入侵者设法在容器内提升到 root 权限，也更难造成严重破坏或提升到主机。这不会影响常规 Web 应用，但大大减少了恶意用户的攻击向量。默认情况下，Docker 删除所有不需要的能力，采用允许列表而非拒绝列表的方法。你可以在 Linux 手册页 中查看可用能力的完整列表。
运行 Docker 容器的一个主要风险是，默认提供给容器的能力集和挂载可能提供不完整的隔离，无论是独立的，还是与内核漏洞结合使用时。
Docker 支持添加和删除能力，允许使用非默认配置文件。这可能通过删除能力使 Docker 更安全，或通过添加能力使 Docker 更不安全。用户的最佳实践是删除除进程明确需要之外的所有能力。
Docker 内容信任签名验证
Docker Engine 可以配置为仅运行已签名的镜像。Docker 内容信任签名验证功能直接内置在 dockerd 二进制文件中。这在 Dockerd 配置文件中配置。
要启用此功能，可以在 daemon.json 中配置信任固定，这样只能拉取和运行使用用户指定的根密钥签名的仓库。
此功能为管理员提供了比之前通过 CLI 执行镜像签名验证更深入的洞察。
有关配置 Docker 内容信任签名验证的更多信息，请访问 Docker 中的内容信任。
其他内核安全功能
能力只是现代 Linux 内核提供的众多安全功能之一。还可以利用现有、知名系统，如 TOMOYO、AppArmor、SELinux、GRSEC 等与 Docker 配合使用。
虽然 Docker 当前仅启用能力，但它不干扰其他系统。这意味着有许多不同的方法来加固 Docker 主机。以下是几个示例。
- 你可以运行带有 GRSEC 和 PAX 的内核。这增加了许多安全检查，无论是在编译时还是运行时；它还通过地址随机化等技术击败了许多漏洞利用。它不需要 Docker 特定的配置，因为这些安全功能适用于整个系统，独立于容器。
- 如果你的发行版带有 Docker 容器的安全模型模板，你可以直接使用它们。例如，我们提供了一个与 AppArmor 配合使用的模板，Red Hat 提供了适用于 Docker 的 SELinux 策略。这些模板提供了额外的安全网（即使它与能力有很大重叠）。
- 你可以使用你喜欢的访问控制机制定义自己的策略。
就像你可以使用第三方工具来增强 Docker 容器一样，包括特殊的网络拓扑或共享文件系统，也存在无需修改 Docker 本身即可加固 Docker 容器的工具。
从 Docker 1.10 开始，用户命名空间直接由 docker 守护进程支持。此功能允许将容器中的 root 用户映射到容器外的非 uid-0 用户，这有助于减轻容器逃逸的风险。此功能可用但默认未启用。
有关此功能的更多信息，请参阅命令行参考中的 守护进程命令。有关 Docker 中用户命名空间实现的其他信息可以在 此博客文章 中找到。
结论
默认情况下，Docker 容器相当安全；特别是如果你在容器内以非特权用户身份运行进程。
你可以通过启用 AppArmor、SELinux、GRSEC 或另一个适当的安全加固系统来增加额外的安全层。
如果你想到让 docker 更安全的方法，我们欢迎功能请求、拉取请求或 Docker 社区论坛上的评论。