NetworkPolicy 隔离：AI 平台默认不该所有服务互通

NetworkPolicy 隔离AI 平台默认不该所有服务互通一、默认互通在 AI 平台里风险很高很多 Kubernetes 集群默认 Pod 之间可以互相访问。对简单系统这能减少配置成本对 AI 平台这个默认很危险。模型服务、向量库、对象存储代理、控制面和业务网关都有不同权限。如果所有服务互通一次应用漏洞就可能横向移动。NetworkPolicy 的目标不是制造复杂网络而是建立最小访问边界。谁能访问模型服务模型服务能访问哪些下游都应该显式声明。默认拒绝再按需要放行。二、先按命名空间和角色定义通信矩阵不要一上来写 YAML。先画出通信矩阵入口网关到推理服务推理服务到缓存和对象存储控制器到 API Server 和模型仓库。矩阵清楚后再转成策略。flowchart TD A[Ingress Gateway] -- B[Inference Service] B -- C[Vector DB] B -- D[Object Storage Proxy] E[Platform Controller] -- B F[Batch Worker] -- B G[Unknown Pod] -.阻断.- B这张图里的虚线同样重要。要明确哪些访问不应该发生。三、用默认拒绝策略打底下面示例给推理命名空间设置默认拒绝入站再由后续策略放行指定来源。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: ai-inference spec: podSelector: {} policyTypes: - Ingress默认拒绝上线前要灰度验证。否则漏掉依赖会直接造成服务不可用。可以先在测试命名空间跑策略再用流量回放确认。四、网络隔离要和身份认证一起做NetworkPolicy 只能控制网络路径不能替代应用认证。允许访问模型服务的 Pod仍然要携带合法身份和权限。网络层负责减少攻击面应用层负责判断能做什么。还要注意 DNS、监控和日志流量。默认拒绝后服务可能无法访问 DNS 或指标采集器。策略中要明确放行必要系统组件。很多 NetworkPolicy 事故不是业务链路错而是基础依赖被挡住。最后策略需要审计。新增服务时必须更新通信矩阵不能靠临时放开整个命名空间解决问题。临时放开最容易变成永久漏洞。出站策略也不能忽略。模型服务通常需要访问对象存储、向量库或模型仓库但不应该默认访问任意外网。可以把外部依赖收敛到代理服务再让策略只放行代理地址。这样既方便审计也能在外部服务异常时统一熔断。排障时要准备策略命中检查。网络不可达时先确认 DNS、Service、Endpoint再看 NetworkPolicy。不要一上来删除策略验证问题。更好的方式是在临时测试 Pod 中使用相同标签复现访问路径并把结果写回通信矩阵。策略变更也需要发布流程。每次新增放行规则都应说明业务原因、来源标签、目标端口和预计保留时间。临时调试规则要自动过期。网络策略如果只增不减几个月后就会退化成另一种默认互通。同时要把拒绝日志接入统一检索否则策略生效后很难定位是谁被挡住。五、总结AI 平台的 NetworkPolicy 应以默认拒绝为起点再按通信矩阵放行必要路径。网络隔离不能替代身份认证但能显著降低横向移动风险。上线策略前要灰度验证 DNS、监控和业务依赖。基础设施要托底第一步就是不要让所有服务默认互相信任。