--privileged=false 无实际禁用作用，真正禁止特权需省略该参数并组合使用 --cap-drop=all、--user、只读挂载、禁用设备映射等措施，辅以运行时验证和集群级策略管控。
直接在启动容器时明确设置 --privileged=false 并不能“强制禁止”特权——因为该参数默认就是 false，它本身不具有主动禁用能力，而只是显式声明当前不启用特权模式。真正起作用的是**不加 --privileged 参数**，或配合其他硬性约束手段。
理解 --privileged=false 的实际含义
这个写法容易造成误解：
- Docker 中 --privileged 是一个布尔型开关，未指定即为 false；
- 显式写 --privileged=false 不会改变默认行为，也不构成安全加固；
- 它既不会移除已有能力，也无法阻止通过其他方式（如 cap-add）提权。
真正有效的禁止特权方法
要实质性阻断容器获取主机物理级权限，需组合以下措施：
- 完全省略 --privileged 参数：这是最基础、最可靠的起点
-
显式裁剪能力集：使用
--cap-drop=ALL移除全部默认能力，再按需添加必要项（如--cap-add=NET_BIND_SERVICE） -
强制指定非 root 用户：在 Dockerfile 中用
USER 1001，或运行时加--user 1001:1001 -
挂载关键路径为只读：例如
-v /proc:/proc:ro -v /sys:/sys:ro，防止篡改内核接口 -
禁用敏感设备挂载：避免
--device或/dev全量映射，尤其防范/dev/sda、/dev/kvm等物理设备暴露
运行时验证是否真被限制
容器启动后，可进入检查关键指标：
- 执行
cat /proc/1/status | grep CapEff：若输出为0000000000000000，说明能力已被清空 - 尝试
mount /dev/sda1 /mnt：应报错Operation not permitted - 查看
/proc/1/status中的CapBnd和CapPrm字段，确认无cap_sys_admin等高危位 - 运行
ls -l /dev/：不应出现宿主机原始块设备节点（如 sda、nvme0n1）
集群环境下的统一管控
在 Kubernetes 或企业级 Docker daemon 环境中，单靠命令行不可靠，应结合：
-
daemon.json 配置默认 drop：
"default-ulimits": {"nofile": {"Name": "nofile", "Hard": 65536, "Soft": 65536}}, "default-capabilities": ["-ALL"] - PodSecurityPolicy 或 Pod Security Admission：禁止 privileged、hostPID、hostIPC、hostNetwork 等字段
- OCI 运行时策略（如 crun + seccomp + apparmor）：在运行时拦截 mount、setns、init_module 等敏感系统调用
