Network Policy网络隔离：限制服务间通信
在现代云原生AI平台中，一个看似微不足道的容器一旦被攻破，就可能成为攻击者横向移动的跳板——从低权限的数据预处理服务一路渗透到承载核心模型权重的推理节点。这种“内部畅通无阻”的默认网络行为，在大模型训练与部署场景下尤为危险。试想一下，某次分布式训练任务因依赖包漏洞遭到入侵，而该Pod恰好能直接访问外部公网，那么未经加密的梯度信息或中间参数就可能悄然外泄。这并非危言耸听，而是许多企业级AI平台在初期阶段都曾面临的现实威胁。
正是在这种背景下，Kubernetes原生的Network Policy技术逐渐从“可选项”转变为“必选项”。它不像Service Mesh那样工作在应用层，也不依赖复杂的Sidecar代理，而是通过L3/L4层面的规则控制，为Pod之间的通信建立一道轻量且高效的数字围栏。尤其当你的集群运行着上百个训练任务、多个租户共享资源时，这套机制几乎是实现安全多租户架构的基石。
Network Policy 的本质是 Kubernetes 提供的一个 API 对象（networking.k8s.io/v1/NetworkPolicy），但它本身并不执行任何过滤动作。它的作用更像是“策略声明”，真正的拦截逻辑由支持策略的 CNI 插件来完成——比如 Calico 使用 iptables 和 Felix 组件，Cilium 则利用 eBPF 直接在内核态进行数据包匹配。这意味着策略的生效前提是：你使用的网络插件必须明确支持 Network Policy 功能。否则，即使定义了再多规则，Kubernetes 依然会维持“默认允许”的开放状态。
其核心工作机制围绕三个关键点展开：首先是标签选择器（label selector），用于精确圈定策略作用的目标 Pod；其次是策略控制器，监听API变更并将高级策略翻译成底层规则；最后是各节点上的执行引擎，将这些规则落地为实际的防火墙策略。整个过程对应用透明，无需修改代码或重启服务。
流量控制分为两个方向：Ingress决定谁可以访问我，Egress决定我可以访问谁。这一点特别重要——传统网络安全往往只关注入口防护，但在微服务环境中，出站流量才是数据泄露的主要路径之一。例如，某个被植入恶意代码的训练容器试图连接境外C2服务器，如果没有Egress限制，这种行为几乎无法被阻止。
更进一步的是，默认策略模型的转变。在没有配置任何 Network Policy 之前，所有Pod之间可以自由通信；但只要在某个命名空间中创建了至少一条策略，就会触发“默认拒绝”行为——未被显式允许的所有连接都将被丢弃。这是实现零信任网络的第一步：不相信任何连接，除非它已被验证和授权。
来看一个典型场景：我们希望模型训练Pod仅接收来自特定推理服务的请求。这种需求常见于微调流程中，其中推理网关需要拉取最新版本的模型进行热更新，但其他组件不应具备此权限。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-inference-to-trainer namespace: ai-training spec: podSelector: matchLabels: component: model-trainer policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: ai-serving podSelector: matchLabels: app: model-inference ports: - protocol: TCP port: 8080这段YAML的作用很明确：只有ai-serving命名空间下、标签为app: model-inference的Pod，才能通过TCP 8080端口访问ai-training中的训练实例。其他所有来源，包括同命名空间内的其他Pod，一律禁止。这里使用了双重选择器（namespace + pod），确保了跨空间调用的安全边界。
再看另一个高风险场景：防止训练任务意外泄露敏感数据。大模型训练常涉及私有语料库甚至客户数据，若不加约束，一个错误配置的脚本就可能导致数据上传至公网存储。为此，我们可以主动封锁所有非必要的出站连接：
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-egress-to-internet namespace: ai-training spec: podSelector: matchLabels: component: model-trainer policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.0/8 - ipBlock: cidr: 172.16.0.0/12 - ipBlock: cidr: 192.168.0.0/16 ports: - protocol: TCP port: 53 - protocol: UDP port: 53 - to: - ipBlock: cidr: 10.96.0.0/12 ports: - protocol: TCP port: 443这个策略允许训练Pod访问集群内部IP段（VPC范围）以及DNS服务（UDP/TCP 53），同时放行Kubernetes Service CIDR中的HTTPS通信（如镜像仓库下载）。注意，这里没有开放任意公网地址，任何试图连接huggingface.co或aws.amazon.com的请求都会被拦截。如果确实需要访问外部模型库，最佳做法是通过企业级代理统一出口，并在此策略中仅允许目标代理IP。
最基础但也最关键的一步，是启用默认拒绝策略。这相当于为整个命名空间设置了一个“安全基线”：
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: ai-production spec: podSelector: {} policyTypes: - Ingress - Egress虽然内容极简，但影响深远：此后所有网络通信都必须通过额外的白名单策略显式放行。很多团队会在上线前先部署这条规则，在测试环境中观察哪些合法流量被误拦，从而逐步完善策略集。这是一种典型的“由紧到松”的安全演进路径。
在基于 ms-swift 框架构建的大模型平台中，这种策略设计显得尤为重要。整个系统涵盖模型下载、分布式训练、微调合并、推理服务、自动评测等多个环节，各组件分布在不同命名空间：
swift-training：运行各类训练任务swift-serving：托管推理API网关swift-eval：执行模型打分与对比swift-tools：提供通用工具链
若无网络隔离，任意Pod均可尝试直连其他服务的ClusterIP，甚至扫描端口探测接口。而借助 Network Policy，我们可以清晰划定每个模块的通信边界。例如，评测系统只能从推理服务获取预测结果，但不能反向访问训练作业；训练任务可拉取MinIO中的数据集，但不得发起外部HTTP请求。
实施过程中有几个工程经验值得分享：
首先，优先按命名空间划分安全域。相比仅靠标签隔离，独立命名空间更容易统一管理策略，也便于结合RBAC做权限联动。比如每个租户拥有专属命名空间后，只需复制一套标准策略模板即可快速完成初始化。
其次，避免宽泛规则。不要写port: 0-65535或protocol: all这类“通配符式”策略。应具体到业务所需端口，如PyTorch DDP常用6105~6107，gRPC服务通常用50051。越精细，越安全。
再次，务必考虑DNS影响。一旦开启Egress控制，忘记放行UDP 53端口会导致域名解析失败，进而引发连接超时。建议将DNS规则作为每条Egress策略的标配项。
此外，动态更新能力至关重要。当新增RLHF训练模式需调用奖励模型时，只需追加一条Ingress规则即可，无需重启现有服务。这种灵活性使得策略能够跟上业务迭代节奏。
最后，监控不可忽视。配合Prometheus抓取CNI插件暴露的指标（如Calico的policy_denied_packets_total），可在Grafana中建立“拒绝事件”看板，及时发现异常扫描或配置失误。
回到最初的问题：为什么在AI平台中特别需要 Network Policy？答案在于两个词：复杂性与价值密度。
一方面，大模型流水线涉及的组件远比传统微服务复杂，训练、评估、部署、监控等阶段交织并行，通信路径呈网状增长。手动维护iptables已不现实，必须依靠声明式策略自动化管理。
另一方面，这些系统承载着极高价值资产——不仅是昂贵的GPU算力，更是经过数天训练形成的模型参数、专有数据集和推理逻辑。一次成功的横向攻击可能导致商业机密外泄，甚至被用于生成恶意内容。
因此，Network Policy 不只是一个技术工具，更是支撑企业级AI工程化的基础设施。它让开发者能在共享集群中安心运行敏感任务，也让平台方有能力满足合规审计要求。在“一锤定音”这类支持600+大模型、300+多模态任务的平台上，每一次成功的策略部署，都是对AI生产力的一次守护。
未来，随着eBPF等技术的深入集成，网络策略有望实现更高性能、更低延迟的实时控制。但对于今天而言，掌握如何正确使用 Network Policy，已经足以让你的AI系统在安全性上迈出决定性的一步。
