启用 --privileged 会彻底削弱容器隔离性，开放挂载任意文件系统、操作硬件设备、修改内核参数、加载内核模块及绕过 cgroups/namespace 限制等高危能力。
启用 docker run --privileged 会极大削弱容器隔离性，相当于将宿主机的全部设备和内核能力开放给容器，显著提升被攻击后横向渗透或逃逸的风险。
特权模式到底开放了什么
该参数并非仅“允许访问/dev”这么简单，而是让容器获得以下能力：
- 挂载任意文件系统（包括宿主机根目录、其他容器卷）
- 直接操作 /dev 中的块设备、网络设备、GPU、USB 等硬件资源
- 修改内核参数（如通过 sysctl 或 /proc/sys）
- 加载/卸载内核模块（kmod）
- 绕过大多数 cgroups 与 namespace 的限制（如 pid namespace 不再隔离 init 进程）
常见误用场景与真实风险
很多用户为解决具体问题而盲目加 --privileged，其实多数情况有更安全替代方案：
-
需要访问 USB 设备？ 改用
--device=/dev/bus/usb:/dev/bus/usb或指定设备节点 -
需要运行 systemd 或 Docker-in-Docker？ 使用
--cap-add=SYS_ADMIN --cap-add=NET_ADMIN配合必要 volume 挂载，而非全开特权 -
需要修改网络配置？ 添加
--cap-add=NET_ADMIN即可，无需特权模式 - 调试内核模块？ 应在宿主机完成，容器内加载模块属于高危行为，生产环境应禁止
如果必须使用，如何降低风险
某些测试、CI 或嵌入式开发场景确实难以避免，此时应叠加多重防护：
- 限定容器运行用户：
--user 1001:1001，避免以 root 运行 - 禁用不必要能力：
--cap-drop=ALL --cap-add=SYS_ADMIN --cap-add=NET_ADMIN - 只读挂载关键路径：
-v /etc:/etc:ro -v /usr:/usr:ro - 使用只读根文件系统：
--read-only（需配合 tmpfs 挂载 /tmp、/run 等临时目录） - 限制资源与进程：
--pids-limit=128 --memory=512m --cpus=1
替代方案优先级建议
按安全性从高到低排序，能不用特权就坚决不用：
- 纯 capability 调整（
--cap-add/--cap-drop） - 精确设备映射（
--device） - 特定 sysctl 参数放开（
--sysctl） - 用户命名空间映射（
--userns-remap）增强隔离 - 最后才考虑
--privileged，且仅限可信镜像与受控环境
不复杂但容易忽略：一个特权容器只要能执行 mount --bind / /host，就能完整读写宿主机全部文件系统——这正是它危险的核心原因。
