daemon.json 不支持“容器安全加固白名单”这一原生概念，但可通过配置 icc=false、seccomp-profile、--no-new-privileges 等实现网络、系统调用、权限能力等多维度默认安全基线。`daemon.json` 是 Docker 守护进程的全局配置文件，它**不直接支持“容器安全加固白名单”这种说法**——因为“白名单”在 Docker 安全体系中不是 daemon.json 的原生概念，而是分散体现在多个机制里：比如 `seccomp`（系统调用白名单）、`capabilities`（权限能力白名单）、网络隔离（`icc=false`）、只读文件系统、非 root 用户等。 但你可以通过 `daemon.json` **统一启用并默认强制执行多项关键安全策略**，让所有容器（除非显式覆盖）都运行在更严格、更“白名单化”的基线上。以下是真正实用、生产环境可落地的配置方式：
1. 默认禁用容器间通信（网络白名单起点）
关闭默认互通，相当于把容器网络设为“白名单模式”：只有明确允许的连接才可通过。
在 /etc/docker/daemon.json 中添加：
{
"icc": false,
"iptables": true,
"ip-forward": true
}
✅ 效果：容器之间默认无法互相访问，必须通过自定义 bridge 网络 + 显式 --network-alias 或 DNS 配置才能通信；配合 docker network create --driver bridge --opt com.docker.network.bridge.enable_icc=false 可进一步细化。
2. 全局启用 Seccomp 白名单策略（系统调用级防护）
Seccomp 是最接近“白名单”的机制——它用 JSON 定义哪些系统调用允许执行。Docker 本身不提供内置白名单文件，但你可以指定一个默认策略路径。
先准备一个最小化 seccomp profile（如 /etc/docker/seccomp-default.json），再在 daemon.json 中设为默认：
{
"default-runtime": "runc",
"seccomp-profile": "/etc/docker/seccomp-default.json",
"icc": false
}
⚠️ 注意：Docker 24.0+ 支持 seccomp-profile 字段作为守护进程级默认策略；旧版本需在每个 docker run 中加 --security-opt seccomp=...，无法全局生效。
? 推荐策略原则：禁用 ptrace、mount、chroot、create_module 等高危调用，仅保留 read/write/openat/close/exit_group 等基础调用。
3. 默认裁剪 Linux Capabilities（权限能力白名单）
Docker 默认已 drop 多数危险 capability，但未显式声明即等于“依赖默认行为”，不够可靠。可在 daemon.json 中强化为显式白名单式管控：
虽然 daemon.json 不能直接写 cap-add/cap-drop，但你可以结合 runtime 配置 + 启动参数实现效果：
- 使用
runc运行时，并在/etc/docker/daemon.json中设置：
{
"default-ulimits": {
"nofile": {"Name": "nofile", "Hard": 65536, "Soft": 65536}
},
"default-runtime": "runc",
"runtimes": {
"runc": {
"path": "runc",
"runtimeArgs": [
"--no-new-privileges"
]
}
}
}
✅ --no-new-privileges 阻止容器内进程通过 execve 获得新权限，是能力白名单的重要补充；配合容器启动时显式 --cap-drop=ALL --cap-add=CHOWN,SETGID,SETUID 才构成完整能力白名单。
4. 强制只读根文件系统 + 临时文件隔离
这不是 daemon.json 原生字段，但可通过 default runtime 参数或容器级策略间接推动：
- 在 daemon.json 中启用
default-shm-size和default-ulimits，限制资源滥用面 - 配合 CI/CD 或 Kubernetes PodSecurityPolicy，统一注入
--read-only和--tmpfs /tmp:rw,noexec,nosuid,size=64m - 若用 docker-compose，可在
secure-container.yml中固化这些选项，形成事实上的“部署白名单”
? 实际生产中，“白名单”不是靠单个配置实现的，而是一套组合策略：daemon.json 设底线 → 镜像层做最小化（Alpine + 非 root 用户）→ 运行时加 seccomp/cap-drop/read-only → 编排层做校验（如 OPA/Gatekeeper）。
