实际上，不，如果用户有权运行docker守护程序，那么他们将有权访问所有图像-这是由于docker要求更高的权限才能运行。

有关为什么这样做的更多信息，请参阅Docker安全指南的摘录。

Docker守护程序攻击面

使用Docker运行容器（和应用程序）意味着运行Docker守护进程。该守护程序当前需要root特权，因此您应该注意一些重要的细节。

首先，应仅允许受信任的用户控制您的Docker守护程序。这是一些强大的Docker功能的直接结果。具体来说，Docker允许您在Docker主机和来宾容器之间共享目录。并且它允许您这样做，而不会限制容器的访问权限。这意味着您可以启动一个容器，其中/
host目录将是主机上的/目录；并且该容器将能够不受任何限制地更改您的主机文件系统。这类似于虚拟化系统允许文件系统资源共享的方式。没有什么可以阻止您与虚拟机共享根文件系统（甚至根块设备）。

这具有很强的安全隐含性：例如，如果从Web服务器检测Docker以通过API设置容器，则在进行参数检查时应比平时更加​​谨慎，以确保恶意用户无法传递导致Docker的特制参数。创建任意容器。

因此，REST API端点（由Docker CLI使用以与Docker守护程序进行通信）在Docker
0.5.2中进行了更改，现在使用UNIX套接字而不是绑定在127.0.0.1上的TCP套接字（后者倾向于如果您碰巧直接在虚拟机外部的本地计算机上运行Docker，则将进行跨站点请求伪造攻击）。然后，您可以使用传统的UNIX权限检查来限制对控制套接字的访问。

如果您明确决定这样做，也可以通过HTTP公开REST
API。但是，如果您这样做了，请注意上述安全隐患，应确保只有从受信任的网络或VPN才能访问该安全隐患。或使用例如通道和客户端SSL证书进行保护。您还可以使用HTTPS和证书保护它们。

该守护程序还可能容易受到其他输入的攻击，例如使用“ docker load”从磁盘或通过“ docker
pull”从网络加载映像。这一直是社区改进的重点，尤其是对于“拉动”安全性。尽管这些重叠，但应注意，“ docker
load”是用于备份和还原的机制，当前不被视为用于加载映像的安全机制。从Docker 1.3.2开始，现在在Linux /
Unix平台上的chroot子进程中提取图像，这是朝着特权分离的更广泛努力的第一步。

最终，预计Docker守护程序将运行受限制的特权，委派经过良好审计的操作子进程，每个子进程都具有自己（非常有限）的Linux功能，虚拟网络设置，文件系统管理等范围。
，Docker引擎本身的片段将在容器内部运行。

最后，如果您在服务器上运行Docker，建议仅在服务器上运行Docker，并在Docker控制的容器内移动所有其他服务。当然，保留您喜欢的管理工具（可能至少是SSH服务器）以及现有的监视/监督过程（例如，NRPE，收集的等）是很好的。