Docker容器安全隔离架构依赖三大核心机制：命名空间隔离（如Network Namespace实现网络视图独占）、自定义bridge网络分段（避免默认docker0互通）、cgroups资源硬限制（CPU/内存）及User Namespace用户映射（降权防逃逸）。

Docker 容器安全隔离架构不是靠背概念学会的，得从底层机制出发，边理解边动手验证。核心就三点：命名空间隔离、资源控制、网络分段。学得对路，两周就能搭出可落地的企业级隔离模型。

搞懂 Network Namespace 是起点

容器网络隔离的本质是每个容器独占一套网络视图——IP、端口、路由表、DNS 都互不可见。这不是 Docker 自己造的，而是 Linux 内核提供的 Network Namespace。你可以用这个命令直观看到：

docker run -it --rm alpine ip link show

再对比宿主机：

ip link show

Docker Cli

使用 Docker CLI 构建、运行、停止、检查和管理容器与镜像的助手。用于执行容器相关任务。

下载

你会发现容器里只有 lo 和 eth0，宿主机却有一堆接口（包括 docker0、vethxxx）。这就是命名空间生效的表现：容器看不到宿主机的网卡，宿主机也看不到容器内部的网络细节。建议用 nsenter 进入容器命名空间手动查路由表和 iptables，比看文档更直接。

bridge 网络别只用默认的 docker0

默认 bridge 模式虽然方便，但所有容器默认互通，不符合生产隔离要求。真正安全的做法是：

• 为不同业务域创建独立自定义桥接网络，比如：docker network create --subnet=10.10.1.0/24 app-prod 和 docker network create --subnet=10.10.2.0/24 app-staging
• 启动容器时显式指定网络：docker run -d --name api --network app-prod nginx
• 验证隔离效果：跨网络容器 ping 不通，docker exec api ping db 会失败，除非两者同属一个网络

注意：自定义网络自带 DNS 解析（容器名即主机名），而默认 bridge 不支持，这是安全+可用的双重提升。

配合 cgroups 做资源硬隔离

光有网络隔离不够，一个容器 CPU 或内存打满，照样拖垮整台宿主机。必须限制资源边界：

docker run -d --cpus="1.5" --memory="512m" --memory-swap="512m" nginx

关键点：

• --memory-swap 必须等于 --memory，否则 swap 会绕过内存限制
• 用 docker stats 实时观察实际占用，避免配置后无反馈
• 生产环境建议结合 systemd 启动容器，并在 unit 文件中写死 LimitCPU / MemoryMax，防止 Docker CLI 被误调用绕过限制

别漏掉 User Namespace 映射

默认情况下，容器内 root 用户在宿主机上仍是 root，一旦逃逸风险极高。启用用户命名空间能从根本上降权：

• 启动 daemon 时加参数：--userns-remap=default
• 或在 /etc/docker/daemon.json 中配置：{"userns-remap": "default"}
• 重启 Docker 后，容器内 UID 0 会被映射成宿主机上一个普通 UID（如 100000+），即使逃逸也无法操作宿主机关键路径

这个功能默认关闭，但它是少数几个能真正缓解“容器逃逸”后果的安全开关之一。 不复杂但容易忽略