将/var/run/docker.sock作为卷挂载到Docker容器的操作与安全风险问题

/var/run/docker.sock是Docker守护进程（dockerd）默认监听的本地Unix域套接字，是Docker客户端与守护进程通信的核心入口。将其挂载到容器后可实现的典型功能包括：

• 容器内直接管控宿主机Docker生命周期：无需在容器内嵌套运行Docker服务（即Docker in Docker方案），即可完成镜像构建、容器启停、日志查询、配置修改等操作，是容器化CI/CD工具（如Jenkins Agent、GitLab Runner）最常用的Docker管控实现方式。
• 开发容器运维管控组件：可在容器内运行监控探针、自动扩缩容服务、服务网格Sidecar等组件，直接拉取宿主机全量容器的运行状态、资源占用、日志数据，动态调整容器调度策略。
• 实现Docker扩展能力：可在容器内运行自定义镜像扫描工具、网络插件、存储插件，直接对接宿主机dockerd完成扩展功能的落地，无需修改宿主机Docker配置。

完全可以。
Docker采用C/S架构，用户执行的docker系列命令本质上是客户端工具，所有实际操作都由宿主机上的dockerd完成，客户端只负责通过/var/run/docker.sock向dockerd发送对应API请求。只要满足两个条件，容器内就能执行所有Docker命令：

1. 容器内的进程对挂载进来的docker.sock有读写权限（默认容器内root用户拥有该权限）
2. 容器内存在可调用API的客户端：既可以是安装的docker二进制命令行工具，也可以直接用curl等工具发送原生HTTP请求，不需要额外依赖。

不止docker stop，docker start/docker rm/docker run/docker exec等所有你能在宿主机上执行的Docker命令，在容器内执行的效果完全一致。

这种挂载方式本质是将宿主机dockerd的完整控制权开放给容器内的授权用户，当容器以root用户运行时，常规的容器隔离机制（只读文件系统、Capabilities裁剪、资源限制）都会完全失效，容器内root用户可直接执行的高危操作包括：

• 破坏宿主机业务可用性：执行docker stop/docker rm -f批量关停、删除宿主机上所有运行的业务容器、系统组件容器，直接造成服务中断。
• 直接获取宿主机root权限：执行如下命令即可在无额外提权操作的前提下，直接拿到宿主机的root shell，完全控制宿主机：

  docker run -v /:/hostfs --rm -it alpine chroot /hostfs sh
  

  拿到宿主机权限后可任意篡改系统配置（如添加后门用户、篡改系统命令）、窃取敏感数据（如SSH私钥、数据库文件、业务密钥）、植入挖矿程序或木马。
• 跨容器渗透：通过docker exec命令可直接进入宿主机上任意运行的其他容器内部，窃取其他容器内的敏感数据、注入恶意代码，绕过容器间的网络隔离、权限隔离。
• 持久化植入恶意程序：可修改dockerd全局配置，将默认镜像源替换为恶意镜像仓库，后续宿主机拉取的所有业务镜像都会被替换为植入后门的版本，实现长期驻留。

核心风险逻辑：dockerd本身默认以宿主机root权限运行，所有通过sock下发的API请求都会被dockerd以宿主机root身份执行，相当于只要能访问sock，就等价于拥有了宿主机的无限制root权限。

内容的提问来源于stack exchange，提问作者Arun Muthupalaniappan