Kubernetes NetworkPolicy 网络策略隔离与访问控制实战

Kubernetes NetworkPolicy 网络策略隔离与访问控制实战

在 Kubernetes 默认网络模型中，“所有 Pod 之间默认全通（All-to-All Connected）”是一项基础设计原则。然而在多租户、金融结算以及大模型核心算力集群中，这种全通模型带来了巨大的安全横向移动（Lateral Movement）风险：

• 一个存在 RCE 漏洞的外部 Web 容器被黑客攻破后，攻击者可以直接在内网跨命名空间扫描并连接 MySQL 数据库与 GPU 推理节点的管理端口；
• 缺乏微隔离（Micro-segmentation）策略，无法满足企业安全合规审计要求。

基于 Kubernetes 原生的 NetworkPolicy（底层由 Calico / Cilium CNI 驱动），我们可以声明式实现细粒度的容器四层网络访问控制。

本文将通过实战演练，演示如何构建从“默认全阻断（Default Deny）”到“白名单按需放行”的生产级容器网络隔离体系。

flowchart TD
subgraph UntrustedZone[未受信任区域: 前端 Web 容器]
WebPod[Web-Frontend Pod]
end

subgraph SecureZone[受保护核心区: Namespace: ai-serving]
LLMPod[LLM 推理核心 Pod: Port 8000]
DBPod[元数据库 PostgreSQL: Port 5432]
end

WebPod -.->|非法直连 DB 5432| BlockX[NetworkPolicy 规则直接拦截 DROP]
WebPod –>|合法请求 8000| LLMPod
LLMPod –>|内部白名单放行 5432| DBPod

1. 第一步：配置命名空间“默认全阻断（Default Deny）”

在核心命名空间中，第一步必须阻断所有入站（Ingress）与出站（Egress）流量，实施零信任基准：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: ai-serving
spec:
podSelector: {} # 匹配该命名空间下的所有 Pod
policyTypes:
– Ingress
– Egress

2. 第二步：按需建立白名单放行规则

针对大模型推理服务 vllm-service，仅允许指定的网关 Pod 访问其 8000 端口，并仅允许其向特定的数据库出站：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-gateway-to-vllm
namespace: ai-serving
spec:
podSelector:
matchLabels:
app: vllm-llama3
policyTypes:
– Ingress
– Egress
ingress:
– from:
– namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: gateway-ingress
podSelector:
matchLabels:
app: api-gateway
ports:
– protocol: TCP
port: 8000
egress:
– to:
– podSelector:
matchLabels:
app: internal-postgres
ports:
– protocol: TCP
port: 5432
# 必须放行 CoreDNS UDP 53 端口，否则域名解析会超时失败
– to:
– namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
– protocol: UDP
port: 53

3. 生产避坑红线