网络策略不直接控制文件系统访问，其核心作用是管控容器间及容器与宿主机的网络流量；真正限制文件访问需依赖挂载控制、用户命名空间重映射、capabilities裁剪和seccomp系统调用过滤等运行时安全机制。
网络策略本身不直接控制容器对宿主机文件系统的访问——那是靠挂载（mount）和权限机制实现的。但你可以通过组合网络隔离与运行时安全配置，间接阻断容器借由网络途径读取或泄露宿主机敏感文件的能力。关键在于切断“通道”、限制“能力”、缩小“暴露面”。
明确网络策略的边界：它管什么、不管什么
NetworkPolicy 或 Docker 网络规则只管控 IP 层及以上的流量（TCP/UDP 等），无法阻止容器通过 挂载宿主机路径（如 -v /etc:/host-etc）直接读写文件。因此，真正的防护必须分两层：
- 网络层：防止容器把宿主机文件（如
/etc/shadow、/root/.ssh）通过 HTTP、FTP、数据库导出等方式外传 - 运行时层：禁止非法挂载、禁用危险能力、启用用户命名空间重映射
关闭容器通往宿主机的“后门网络通道”
很多攻击会先突破容器，再尝试连接宿主机上监听的本地服务（如 Docker daemon 的 unix:///var/run/docker.sock、kubelet API、SSH、Redis 等），进而读取敏感文件或提权。需针对性封堵：
- 默认拒绝所有出站流量：
egress策略设为空白或仅允许必要域名/IP，尤其禁止访问127.0.0.1和localhost的非必需端口 - 在宿主机 iptables 的
DOCKER-USER链中显式丢弃容器访问127.0.0.1:2375/2376（Docker API）、:10250（kubelet）、:22（SSH）等敏感端口的请求 - 禁用
userland-proxy，确保 iptables 规则真正生效，避免 Go 代理绕过防火墙
隔离容器网络，切断横向渗透路径
即使容器没直连宿主机，也可能通过其他容器（如特权容器、日志收集器、监控 agent）间接访问敏感路径。应构建网络信任链：
- 为不同角色创建独立自定义桥接网络（如
app-net、monitor-net、storage-net），并用--internal标志禁止外部路由 - 用 NetworkPolicy 明确禁止
app类 Pod 访问monitor或backup命名空间中的 Pod，防止其利用日志/备份服务读取宿主机挂载的配置文件 - 对运行
docker.sock挂载的运维类容器，单独置于高隔离网络，并严格限制其入站来源（仅允许 CI/CD 或管理员终端 IP）
运行时加固：让容器“看不见”也“动不了”宿主机文件
网络策略是外围防线，底层加固才是根本：
- 禁用
NET_ADMIN和NET_RAW能力，防止容器操作 iptables、抓包或伪造 ARP 获取局域网信息 - 启用用户命名空间重映射（
--userns-remap=default），使容器内 root 映射为宿主机普通用户，无法修改/etc或/boot等关键目录 - 挂载宿主机路径时坚持只读（
:ro），且绝不挂载/、/etc、/proc、/sys等敏感根路径；如需配置，改用 ConfigMap/Secret 注入 - 使用 seccomp profile 屏蔽
openat、readlink、chroot等可能用于遍历挂载点的系统调用
验证是否真正隔离
执行以下检查确认防护有效：
- 进容器运行
curl -v http://127.0.0.1:2375/version→ 应超时或被拒绝（非 403） - 查
iptables -L DOCKER-USER -n→ 应含明确 drop 规则 - 运行
docker inspect <container> | grep -i 'host.*path\|cap\|userns'</container>→ 不应出现可写挂载、NET_ADMIN、未启用 user namespace - 尝试
nsenter -t $(pidof containerd) -m -p cat /etc/shadow（需 host 权限）→ 容器进程不应有此能力
