北京
Kubernetes网络安全的长期缺口
在Kubernetes体系里，网络隔离长期被当作开发者的分内事。标准的NetworkPolicy对象只作用于单个命名空间，应用边界内做微服务隔离没问题，一旦集群扩大到多个团队、业务线和环境，平台管理员就抓瞎了：没有原生机制去设置全局安全护栏。
想阻止所有Pod访问云元数据服务器，或者把某些命名空间和其他所有命名空间彻底隔开，过去只能靠复杂的策略引擎、自定义准入控制器，或者自动化注入一堆命名空间级策略。这套做法既脆弱，审计起来也费劲。
ClusterNetworkPolicy如何改变规则
GKE新推出的ClusterNetworkPolicy目前处于公开预览阶段，它引入了一个集群级资源，让安全和平台团队能跨所有命名空间建立不可被覆盖的安全边界。要理解它，得先看GKE怎么评估网络流量。
标准命名空间级NetworkPolicy是“叠加式”的：多个策略选中同一个Pod时，只要有一条策略放行，流量就放行。ClusterNetworkPolicy不一样，它走严格的顺序评估管线，第一条匹配的规则直接生效。
流量按顺序经过三个策略层级：Admin层、Baseline层，以及命名空间级策略。每个层级内部，策略按显式数字优先级评估，范围是0到1000，数字越小优先级越高。单个策略对象内部，规则从上到下依次判断。
三种动作与Pass的平衡设计
ClusterNetworkPolicy的每条规则必须触发三种动作之一：Allow、Deny或Pass。其中Pass动作尤其值得注意，它让平台管理员可以针对特定流量做放行委托。
比如把8080端口的Web流量单独拎出来，交给命名空间所有者做最终决定。这类流量会跳过Admin层剩余规则，转由标准命名空间级网络策略评估。命名空间所有者配置了接受策略就放行；没有配置，流量继续进入Baseline层。这个设计在集中合规和开发者自主之间找到了一个折中点。
一个隔离敏感命名空间的示例
假设要把一个敏感命名空间和所有集群内部流量隔离开。把策略放进Admin层，就能保证命名空间级策略无法覆盖它。下面是一个针对敏感命名空间的全局拒绝策略清单：
- apiVersion: policy.networking.k8s.io/v1alpha2
- kind: ClusterNetworkPolicy
- metadata.name: cluster-wide-deny-sensitive
- spec.tier: Admin
- spec.priority: 10
- subject.namespaces.matchLabels: kubernetes.io/metadata.name: sensitive-ns
这个清单的核心是tier字段设为Admin，priority设为10，subject通过标签匹配sensitive-ns命名空间。管理员一旦部署，该命名空间的隔离边界就固定下来，后续任何命名空间级策略都无法改变它。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
