问题
服务运行环境是 k8s ，如果要执行 docker 命令，主要是安全问题，如何避免容器逃逸？
AI 提供了两种解决方案
- 挂载主机 sock 使用 dind 执行 docker 命令
- 使用 buildx/buildkit ，维护一个专门执行 docker 命令的集群提供 docker 能力
想问下大家有没有遇到类似的问题，如何解决的？
第 1 条附言 2025 年 9 月 1 日
找到了历史的回答： https://v2ex.com/t/1139075
 | 1 weilai99 2025 年 9 月 1 日 用 kaniko |
 | 2 SmallZheng 2025 年 9 月 1 日 kaniko +1 |
 | 3 anubu 2025 年 9 月 1 日  1 kaniko 不再维护了，但应该能继续用。docker 有 dind 镜像，sidecar 挂给业务容器，或 daemonset 每个节点放一个应该都行。 |
 | 4 orFish 2025 年 9 月 1 日 |
 | 5 danbai PRO 1 可以看看 firecracker-containerd 据描述他的隔离级别是对标 qemu |
 | 6 Clannad0708 2025 年 9 月 1 日 1 我工作接触过的，一种用 dind ，将宿主机的 sock 挂在进去，就是 dind 。还有可以试下用安全容器技术，katacontainer ，gvisor 。他们有自己的 sandbox 隔离容器。不和宿主机共享内核 |
 | 8 ExplodingDragon 2025 年 9 月 2 日 1 kaniko 算是侵入性最小的方案了，而且只是没有新特性更新了，错误修复还是在继续进行: https://github.com/chainguard-dev/kaniko 或者就是使用 sysbox : https://github.com/nestybox/sysbox 处理部分执行权限问题然后在 pod 内用 docker/podman 最后就是：不要考虑任何依赖特权模式的解决方案 |
| 9 weilai99 2025 年 9 月 2 日 buildah 也行 |
 | 10 sampeng 2025 年 9 月 2 日 以前我也焦虑这个问题。后来想明白了。。这都是自己吓自己。没有任何手段从外部进来。docker build 也是自己写，ci 自动调度的。哪来的 docker 逃逸呢？ |
 | 11 standchan 2025 年 9 月 2 日 buildkit |
 | 12 Lee2019 2025 年 9 月 2 日 docker context 配置一个远端的 docker host ，容器里面只要有 docker cli 即可 |
 | 13 julyclyde 2025 年 9 月 6 日 我还以为在“里面”运行一个 docker daemon 才叫 dind 呢 没想到居然是挂外边的 sock 进去？？ |
 /td> | 14 zidy 2025 年 10 月 8 日 1 buildkit rootless 模式。 |
Select Language