Docker 不支持通过配置文件全局禁用 bind mount，因其设计遵循“运行时声明”原则，daemon.json 等配置不提供挂载类型过滤机制；可行约束需依赖 CI/CD 校验、CLI 封装、内核防护及权限审计等组合手段。
不能通过配置文件“强制禁止 bind mount”——docker 本身不提供全局禁用 -v 绑定挂载的策略开关。所有挂载行为（包括 bind mount 和 volume）均由 docker run 或 docker compose 命令在运行时决定，docker daemon 没有内置的白名单/黑名单式挂载类型限制机制。
为什么没有全局禁用 bind mount 的配置项
Docker 的设计哲学是“运行时声明”，而非“守护进程策略管控”。daemon.json 支持的选项（如 default-ulimits、iptables、userns-remap）均不涉及挂载类型过滤。即使启用 live-restore 或 experimental，也无 disable-bind-mount 类参数。
可行的替代约束路径
虽无法直接禁止 bind mount，但可通过组合手段大幅提高违规成本、降低误用概率：
-
统一使用 Docker Compose + 自定义模板校验：在 CI/CD 流水线中接入 YAML 解析器（如 yq 或自研脚本），拒绝含
./、/home/、/opt/等典型宿主机绝对路径的volumes:条目；只允许命名卷（如db-data:）或volume:显式块 -
替换默认 docker CLI 为封装 wrapper：部署一个 shell 函数或二进制代理（如
safe-docker），拦截run、create命令，检查-v参数值是否匹配正则^/.*?:或^[a-zA-Z]:\.*?:（Windows），命中即报错退出 -
运行时内核级防护（需 systemd + cgroups v2）：在
/etc/systemd/system/docker.service.d/override.conf中添加：Environment="DOCKER_OPTS=--default-runtime=runc --security-opt=no-new-privileges"，再配合 seccomp profile 禁用mount系统调用对非tmpfs/overlay类型的访问（实际效果有限，且影响 volume 创建） -
权限与审计兜底：将宿主机敏感路径（如
/、/etc、/var/lib/docker）设为chmod 700并属主限定；启用auditd监控mount系统调用，告警异常 bind 操作
推荐的生产实践组合
真正落地有效的做法不是“堵死 bind”，而是“引导只用 volume”：
- 在团队文档中明确定义：所有持久化数据必须使用
docker volume create创建命名卷，挂载时仅写-v myapp-data:/data，禁用任何形式的-v /host/path:/container/path - Dockerfile 中用
VOLUME ["/data"]声明预期挂载点，配合 HEALTHCHECK 验证该路径是否为 volume（检查/proc/mounts中对应条目是否含driver:local） - CI 构建阶段执行
docker inspect $IMAGE | jq '.[].Config.Volumes'，确保镜像未硬编码绑定路径 - 集群环境（如 Swarm/K8s）直接弃用
docker run -v，全部迁移至docker stack deploy+volumes:块，天然隔离 bind mount
