为什么你的Docker容器还在共享宿主机网络？3步强制启用默认隔离模式，附12条iptables审计checklist

第一章：Docker网络隔离配置的核心原理与风险全景

Docker 网络隔离并非简单的“容器间不能通信”，而是由 Linux 内核的命名空间（network namespace）、虚拟以太网设备（veth pair）、网桥（bridge）及 iptables/nftables 规则共同构成的分层控制体系。每个 Docker 网络（如 bridge、overlay、macvlan）背后都绑定一组独立的 network namespace，容器进程被挂载其中，从而实现网络协议栈、接口、路由表、防火墙规则的完全隔离。

核心隔离机制

• Network Namespace：为每个容器提供独立的网络视图，包括 loopback 接口、IP 地址、端口空间和路由表
• veth Pair + Bridge：容器内 veth 设备与宿主机网桥（如 docker0）通过配对连接，桥接实现同一网络内容器互通
• iptables/nftables 链式过滤：Docker 自动在 FORWARD、DOCKER-USER 等链中插入策略，控制跨网络流量与端口映射（-p）行为

典型风险场景

风险类型	触发条件	潜在影响
host 网络模式滥用	docker run --network=host	容器共享宿主机网络栈，绕过所有隔离，暴露敏感端口与路由
DOCKER-USER 链缺失自定义规则	未在 iptables -t filter -I DOCKER-USER 中设置前置拦截	外部流量可穿透默认 ACCEPT 策略，攻击容器服务

验证网络隔离状态

# 查看容器所在 network namespace 的索引
sudo ls -la /proc/$(docker inspect -f '{{.State.Pid}}' my-container)/ns/net

# 检查 docker0 网桥关联的 veth 设备与容器 IP 分配
ip link show | grep veth
docker network inspect bridge | jq '.[0].Containers'

# 列出影响容器间通信的关键 iptables 链
sudo iptables -t filter -L DOCKER-USER -n
sudo iptables -t filter -L FORWARD -n | grep 'docker0\|ACCEPT.*RELATED,ESTABLISHED'

该命令集用于诊断容器是否真正处于隔离上下文中，并确认防火墙策略是否按预期生效——例如，若 FORWARD 链中存在无限制的 ACCEPT 规则且位于 DOCKER-USER 之前，则隔离已实质性失效。

第二章：深入解析Docker默认网络模式与隔离失效根因

2.1 宿主机网络命名空间（host network）的内核级共享机制剖析

宿主机网络命名空间通过 `CLONE_NEWNET` 标志的缺失实现内核级共享，其本质是进程复用 init namespace 的网络设备、路由表与套接字资源。

关键内核路径

// kernel/fork.c: copy_net_ns()
if (clone_flags & CLONE_NEWNET)
    return create_new_net(&net_ns);
else
    return get_net(current->nsproxy->net_ns); // 直接引用宿主 net_ns

该逻辑确保未指定 `--network=host` 的容器默认隔离，而显式启用时跳过命名空间创建，直接复用 `¤t->nsproxy->net_ns`。

共享资源对照表

资源类型	宿主机模式行为	隔离模式行为
lo 接口	同一 netns 实例，状态实时同步	独立 lo，独立 up/down 状态
iptables 规则	共用同一 `xt_table` 链表	各自维护独立规则集

典型验证流程

1. 启动 host-network 容器：`docker run --network=host alpine ip link show lo`
2. 在宿主机执行 `ip link set lo down`，观察容器内 `ip link` 输出同步变为 `DOWN`
3. 验证 `/proc/[pid]/ns/net` 指向与宿主机 `init` 进程完全一致

2.2 docker run --network=host 的隐式继承路径与权限逃逸风险实测

网络命名空间的隐式绑定

当使用 --network=host 时，容器直接复用宿主机的网络命名空间，不创建隔离的 netns：

# 宿主机视角查看网络接口
ip link show | grep -E "^(\\d|lo)"

# 容器内执行相同命令将输出完全一致的结果
docker run --rm --network=host alpine ip link show | grep -E "^(\\d|lo)"

该参数绕过 Docker 网桥（docker0）及 iptables 链拦截，使容器进程等效于宿主机上的普通进程，具备直接操作 /proc/sys/net/ 和绑定特权端口（如 80）的能力。

关键风险对比表

能力项	--network=bridge	--network=host
访问 /proc/sys/net/ipv4/ip_forward	受限（只读挂载）	可读写
监听 22 端口	失败（Permission denied）	成功（无端口映射限制）

逃逸验证步骤

1. 启动 host 网络模式容器并挂载 /proc 为 rshared；
2. 在容器内修改 /proc/sys/net/ipv4/conf/all/forwarding；
3. 验证宿主机路由转发状态已同步变更。

2.3 Docker daemon.json 中 default-address-pools 配置对隔离边界的实质性影响

网络地址池的默认分配逻辑

Docker 20.10+ 引入 default-address-pools，用于约束所有用户自定义桥接网络（非 bridge 默认网络）的子网来源，从而在 IPAM 层面构筑初始隔离边界。

{
  "default-address-pools": [
    {
      "base": "172.30.0.0/16",
      "size": 24
    },
    {
      "base": "10.200.0.0/16",
      "size": 22
    }
  ]
}

该配置强制后续 docker network create --driver bridge 自动从指定池中顺序分配 /24 或 /22 子网，避免跨团队网络重叠。参数 base 定义起始 CIDR，size 指定每次分配的前缀长度，直接影响可创建网络数量与单网络容量。

隔离效果对比

配置状态	子网冲突风险	跨环境复用性
未配置 default-address-pools	高（自动选 172.17–31 等易撞段）	低（依赖人工协调）
配置双池（如上例）	趋近于零	高（按用途划分池）

2.4 容器内/proc/sys/net/ipv4/ip_forward 与宿主机转发策略的耦合验证

内核参数隔离特性

Linux 4.15+ 中，/proc/sys/net/ipv4/ip_forward 在容器内默认继承宿主机值，但仅当启用 net.ipv4.conf.all.forwarding 命名空间支持时才可独立修改。

验证命令对比

# 宿主机查看
cat /proc/sys/net/ipv4/ip_forward

# 容器内查看（默认挂载为只读）
docker run --rm -it alpine cat /proc/sys/net/ipv4/ip_forward

该输出始终一致，因 ip_forward 属于全局命名空间参数，非 per-netns 可调项。

实际生效层级

作用域	是否可独立配置	影响范围
宿主机全局	是	所有网络命名空间
容器 netns	否（仅读）	无独立效果

2.5 overlay2 存储驱动下 netns 文件句柄泄漏导致网络命名空间复用的取证分析

问题现象定位

在 overlay2 驱动下，容器退出后 `/proc/[pid]/ns/net` 符号链接仍被宿主机进程（如 CNI 插件）长期持有，导致 netns inode 未释放。可通过以下命令验证：

# 查找持有 netns 的进程
find /proc/[0-9]*/fd -lname "net:[*]" 2>/dev/null | xargs ls -l

该命令遍历所有进程文件描述符，筛选出指向 netns 的符号链接。若返回非空结果，表明存在句柄泄漏。

关键内核对象关系

对象类型	生命周期依赖	泄漏影响
struct net	refcount > 0 时不可销毁	IP 地址、路由表、iptables 规则持续驻留
overlay2 lower/upper dir	依赖 netns 关闭后才可安全清理	残留导致后续容器复用同一 netns

第三章：三步强制启用默认桥接隔离模式的生产级落地

3.1 步骤一：全局禁用 host 网络并校验 daemon 启动参数（--no-hosts、--userland-proxy=false）

核心参数作用解析

`--no-hosts` 禁用 Docker 自动管理 `/etc/hosts` 文件，避免容器内 DNS 解析冲突；`--userland-proxy=false` 关闭用户态端口转发代理，强制使用内核级 `iptables` 规则，提升网络性能与一致性。

验证 daemon 启动配置

# 检查当前 dockerd 启动参数
ps -ef | grep dockerd | grep -E "(--no-hosts|--userland-proxy=false)"
# 输出应同时包含两项参数

若缺失任一参数，需在 `/etc/docker/daemon.json` 中补全并重启服务。

推荐配置对照表

参数	默认值	安全/生产建议值
--no-hosts	false	true
--userland-proxy	true	false

3.2 步骤二：重建默认 bridge 网络并强制分配独立子网与 MAC 地址池

Docker 默认的 bridge 网络（docker0）在多宿主或网络策略强化场景下易引发 IP 冲突与 MAC 泛洪。需显式重建并隔离资源：

• 移除原有默认桥接网络（需先停用所有容器）
• 指定唯一 CIDR 子网，避免与物理网络重叠
• 预设 MAC 地址范围，防止虚拟网卡地址随机碰撞

# 重建 docker0，使用 172.20.0.0/16 子网，MAC 地址池限定为 02:42:ac:14:00:00–02:42:ac:14:ff:ff
sudo ip link delete docker0
sudo dockerd --bip=172.20.0.1/16 --fixed-cidr=172.20.0.0/16 --default-gateway=172.20.0.1 --max-concurrent-downloads=3 &

参数说明：--bip 设置网桥 IPv4 地址及掩码；--fixed-cidr 限制容器 IP 分配范围；--default-gateway 显式指定默认网关，确保路由一致性。

参数	作用	推荐值
--bip	网桥接口地址	172.20.0.1/16
--default-gateway	容器默认出口网关	172.20.0.1

3.3 步骤三：通过 containerd shim v2 注入 runtime 配置，阻断 net=host 的 OCI 运行时绕过

shim v2 插入点与配置拦截时机

containerd shim v2 允许在 `CreateTask` 阶段动态注入/校验 OCI spec。关键在于重写 `runtime.Options` 字段，而非仅依赖 runc 默认行为。

核心校验逻辑（Go）

// 拦截 net=host 并强制覆盖为隔离网络
if spec.Linux != nil && spec.Linux.Network != nil {
    if spec.Linux.Network.Type == "host" {
        // 阻断并替换为受限桥接网络
        spec.Linux.Network.Type = "bridge"
        spec.Linux.Network.Options = map[string]string{"disable_host_network": "true"}
    }
}

该逻辑在 shim 的 `CreateTask` 中执行，早于 OCI runtime（如 runc）解析 spec，确保 `net=host` 不进入下游运行时。

配置注入对比表

注入位置	是否可绕过 net=host 检查	生效阶段
containerd daemon config	否（runc 仍可直读 spec）	启动前
shim v2 CreateTask	是（spec 已被篡改）	任务创建时

第四章：iptables 规则链深度审计与容器网络策略加固

4.1 检查 DOCKER-USER 链是否存在且优先级高于 FORWARD 主链（含 -t filter -L -n 输出解析）

iptables 链执行顺序关键点

Linux 内核 netfilter 在 filter 表中按固定顺序遍历链：`INPUT → FORWARD → OUTPUT`，而 `DOCKER-USER` 是 Docker 创建的自定义链，**必须挂载在 `FORWARD` 之前**，否则用户规则将被 Docker 自动插入的 `DOCKER-ISOLATION-STAGE-1` 等链绕过。

验证命令与输出解析

sudo iptables -t filter -L -n
# 输出片段示例：
Chain INPUT (policy ACCEPT)
...
Chain FORWARD (policy DROP)
...
Chain DOCKER-USER (1 references)
...  
# 注意：DOCKER-USER 必须出现在 FORWARD 规则中第一条跳转前

该命令列出 filter 表所有链及其引用关系；`DOCKER-USER (1 references)` 表明其已被 `FORWARD` 链显式调用（通常为 `-j DOCKER-USER`），这是确保优先执行的必要条件。

Docker-USER 链调用位置验证表

位置	是否合规	说明
FORWARD 链首条规则	✅ 推荐	确保所有转发包首先进入用户控制面
FORWARD 链末尾	❌ 失效	可能被中间 DROP 规则拦截，无法生效

4.2 审计 iptables -t nat POSTROUTING 中 MASQUERADE 规则是否限定源地址范围

安全风险根源

未限定源地址的 MASQUERADE 规则可能导致非预期流量被伪装，扩大攻击面。理想策略应仅对可信子网执行 SNAT。

合规检查命令

iptables -t nat -L POSTROUTING -n --line-numbers | grep MASQUERADE

该命令列出所有 POSTROUTING 链中的 MASQUERADE 规则及其行号，便于定位与审计。

典型合规规则对比

类型	规则示例	是否合规
宽松	-t nat -A POSTROUTING -o eth0 -j MASQUERADE	否
严格	-t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE	是

修复建议

1. 删除无源限制的 MASQUERADE 规则；
2. 使用 -s 显式指定可信内网段；
3. 通过 iptables-save 持久化配置。

4.3 验证 conntrack 相关规则（如 -m conntrack --ctstate INVALID -j DROP）是否生效于容器流量路径

确认规则在宿主机 iptables 中存在

iptables -t filter -L FORWARD -n -v | grep 'ctstate.*INVALID'
# 输出示例：0     0 DROP       all  --  * *  0.0.0.0/0  0.0.0.0/0  ctstate INVALID

该规则匹配连接跟踪状态为 INVALID 的数据包，并立即丢弃。`ctstate INVALID` 表示内核无法将报文归入任何已知连接，常见于分片缺失、TCP 标志异常或 conntrack 表溢出。

验证容器流量是否经过 FORWARD 链

1. 容器间通信（不同网络命名空间）必经 `FORWARD` 链；
2. Pod-to-Pod 流量在 CNI 桥接模式下同样触发该链；
3. 可通过 `iptables -t filter -L FORWARD -n -v` 中对应规则的 packet 计数器增长确认命中。

关键参数说明

参数	含义
-m conntrack	加载 conntrack 扩展模块
--ctstate INVALID	匹配连接状态为无效的报文（非 ESTABLISHED/RELATED/NEW）

4.4 扫描残留的 --iptables=false 容器残留规则及 ip6tables 对 IPv6 流量的策略盲区

iptables 规则残留现象

当容器以 --iptables=false 启动时，Docker 不管理 iptables 链，但宿主机原有规则（如 DOCKER-USER、DOCKER-ISOLATION-STAGE-1）仍可能残留并影响流量。

# 检查残留链及引用
iptables -t filter -L DOCKER-USER -n --line-numbers
iptables -t filter -S | grep '^-A.*-j DOCKER-USER'

该命令列出 DOCKER-USER 链规则及其被引用位置；若容器已卸载但链未清空，将导致策略误匹配。

IPv6 策略盲区根源

Docker 默认不操作 ip6tables，且多数网络插件（如 bridge）忽略 IPv6 FORWARD 链配置，造成双栈环境下的策略不对称。

协议	默认管理	典型缺失项
IPv4	是（通过 iptables）	—
IPv6	否	ip6tables FORWARD 策略、NDP 保护规则

第五章：容器网络隔离演进趋势与零信任架构展望

从网络策略到身份感知的隔离升级

Kubernetes NetworkPolicy 仅基于 IP、端口和标签实现三层/四层隔离，已难以应对多租户服务网格中细粒度的服务间调用控制。Istio 的 AuthorizationPolicy 引入了 `source.principal` 和 `request.auth.claims` 字段，使策略决策可依赖 mTLS 身份而非静态网络拓扑。

零信任在容器边界的落地实践

某金融云平台将 Open Policy Agent（OPA）嵌入 CNI 插件链，在 Pod 创建阶段动态注入基于 SPIFFE ID 的准入校验逻辑：

package k8s.admission

default allow = false

allow {
  input.request.kind.kind == "Pod"
  input.request.object.spec.containers[_].securityContext.runAsNonRoot == true
  input.request.object.metadata.labels["trust-level"] == "high"
  is_valid_spiffe_id(input.request.object.spec.serviceAccountName)
}

关键能力对比分析

能力维度	传统 NetworkPolicy	零信任增强型策略
认证依据	IP + Namespace 标签	SPIFFE ID + JWT 声明
策略生效时机	Pod 启动后	API Server 准入阶段 + eBPF 数据面实时拦截
可观测性粒度	连接拒绝日志	策略匹配路径、证书链验证详情、RBAC 决策溯源

生产环境演进路线

• 第一阶段：启用 Cilium ClusterMesh + mTLS 全链路加密
• 第二阶段：在 Istio Gateway 层集成 OAuth2 Introspection，校验外部请求令牌有效性
• 第三阶段：通过 eBPF Map 动态加载 OPA 编译后的 Wasm 策略模块，实现毫秒级策略热更新