结论：--privileged 给容器 root 全部 Linux capabilities、放开设备访问、关闭 seccomp/AppArmor 等加固，容器内 root 基本等同宿主机 root——可以挂载宿主机磁盘、加载内核模块、改 sysctl，逃逸从"可能需要漏洞"变成"直接操作"。生产环境几乎不该使用。

展开：细粒度替代按需求逐项授：1）--cap-add NET_ADMIN（配网络）、SYS_PTRACE（调试）、SYS_TIME 等单 capability 取代全量授权，配合默认已裁剪的 capability 集合（Docker 默认只给 14 个，已不含 SYS_ADMIN）；2）单个设备用 --device=/dev/fuse 而非全部设备可见；3）只读根文件系统 --read-only + tmpfs 挂临时目录；4）--security-opt no-new-privileges 禁 setuid 提权；5）用户命名空间（userns-remap）把容器 root 映射成宿主机普通用户——这是纵深防御的底牌，即使逃逸也非宿主 root。真实需要高权限的场景（容器里跑 Docker、systemd、CI 构建）优先用 rootless Docker、sysbox 等专用运行时，而不是 privileged。易错点：挂载 /var/run/docker.sock 等价于给了宿主机 root（可以起 privileged 容器），CI 场景要用 kaniko/buildah 这类无 daemon 构建。

docker run --cap-add NET_ADMIN --device=/dev/net/tun \
  --read-only --security-opt no-new-privileges myvpn

追问方向：capability 的分割粒度历史（CAP_SYS_ADMIN 为何被称为"新 root"）、gVisor/Kata 如何用额外隔离层允许更激进的权限需求。