docker容器安全隔离依赖内核机制、网络配置、运行时策略和镜像管理协同实现。核心是通过命名空间限制可见性（pid/net/mnt/user等）、cgroups约束资源（cpu/内存/pid），结合bridge/host/none等网络模式按需隔离，运行时禁用特权、降权运行、只读挂载、能力裁剪，并采用精简镜像、漏洞扫描与不可变部署强化整体防线。
Docker 容器安全隔离不是靠单一设置实现的，而是由内核机制、网络配置、运行时策略和镜像管理共同构成的体系。核心在于限制容器能“看到什么”和“用到什么”，防止越界访问或资源耗尽。
利用命名空间与 cgroups 强化基础隔离
Linux 命名空间（Namespaces）是容器隔离的底层支撑，每个容器默认拥有独立的 PID、NET、MNT、IPC、UTS 和 USER 命名空间。这意味着：
- 进程看不到其他容器里的进程（PID 隔离）
- 网络接口、IP、端口、路由表完全独立（NET 隔离）
- 文件系统挂载点互不影响（MNT 隔离）
- 用户 ID 可映射为非 root（USER 隔离），避免容器内 root 等同宿主机 root
cgroups 则负责资源硬约束，防止某个容器吃光 CPU、内存或 I/O：
- 启动时加 --memory=512m --cpus=1.5 --pids-limit=100 限制关键资源
- 避免未设限的容器引发 DoS 或拖垮宿主机
按需选择并配置网络模式
网络是攻击面最活跃的部分，隔离不当极易导致横向移动。不同模式适用不同场景：
- bridge（默认）：提供基本隔离，但所有容器在 docker0 网桥下处于同一子网（如 172.17.0.0/16），彼此可直接 IP 访问 —— 生产中应避免让敏感服务共用默认网桥
- 自定义 bridge 网络：用 docker network create isolated-net 创建专属网络，仅加入该网络的容器才能通信，且支持通过容器名 DNS 解析，比 IP 更可控
- host 模式：容器直接使用宿主机网络栈，零隔离 —— 仅限性能严苛且可信度高的组件（如监控代理），禁用于业务容器
- none 模式：无任何网络接口 —— 适合离线计算、加密解密等无需联网的任务
验证是否生效：运行 docker inspect
运行时加固：最小权限 + 不可变性
即使网络和命名空间隔离到位，容器若以 root 运行或挂载敏感路径，仍可能被提权突破：
- 禁止特权模式：--privileged=false（默认已禁，但显式声明更稳妥）
- 降权运行：--user 1001:1001 指定非 root 用户，配合镜像内提前创建好该用户
- 只读挂载关键目录：-v /host/config:/app/config:ro 防止容器篡改配置
- 禁用危险能力：--cap-drop=ALL --cap-add=NET_BIND_SERVICE，只保留必要 Linux Capabilities
- 启用只读根文件系统：--read-only，配合 tmpfs 挂载 /tmp、/run 等临时目录
镜像与生命周期层面的隔离协同
隔离效果会随着镜像构建和部署方式被削弱或增强：
- 使用精简安全的基础镜像（如 distroless 或 alpine:latest），减少攻击面
- 镜像构建阶段就删除包管理器缓存、调试工具（如 apk del .build-deps）
- 扫描镜像漏洞：trivy image your-app:latest，阻断高危镜像上生产
- 容器不可变：禁止 exec 进入生产容器修改配置；所有变更必须通过新镜像+滚动更新实现
