k8s的网络策略
Kubernetes网络策略实战指南:如何锁紧集群的网络流量
一、为什么需要网络策略?生产环境中的真实痛点
Kubernetes默认允许所有Pod自由通信,这给生产环境埋下重大安全隐患。以下是两个真实场景:
- 敏感数据泄露:日志收集Pod意外连接到未授权的数据库Pod,导致数据泄露。
- 横向攻击扩散:黑客入侵前端Pod后,利用开放的网络直接攻击后端的Redis服务。
网络策略(NetworkPolicy) 正是解决这些问题的“虚拟防火墙”。它通过定义白名单规则,实现零信任网络模型——默认拒绝所有流量,仅允许明确声明的通信。
二、网络策略核心概念:像写代码一样定义规则
1. 基础结构:选择器(Selector)与规则类型
每个NetworkPolicy包含三个关键部分:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend
spec:
podSelector: # 目标Pod(被保护的Pod)
matchLabels:
app: backend
policyTypes: # 规则类型(Ingress/Egress)
- Ingress
ingress: # 入站规则
- from: # 允许的流量来源
- podSelector: # 来自其他Pod的条件
matchLabels:
app: frontend
ports: # 允许的端口
- protocol: TCP
port: 8080
- podSelector:用标签选择需要保护的Pod(如
app: backend
)。 - policyTypes:控制入站(Ingress)或出站(Egress)流量。
- from/to:定义流量的来源或目标(支持Pod、Namespace、IP段)。
2. 规则匹配逻辑:精准控制四层流量
- 四层控制:基于IP、端口、协议(TCP/UDP/SCTP)。
- 逻辑组合:
from
或to
中的多个条件是“或”关系,同一块内的条件是“与”关系。
三、生产环境经典场景与配置示例
场景1:禁止所有流量,按需开放
需求:默认拒绝Namespace内所有Pod的入站流量,仅允许监控系统访问。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
spec:
podSelector: {} # 选择所有Pod
policyTypes:
- Ingress
ingress: [] # 无规则表示拒绝所有入站
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-monitoring
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring # 允许监控Namespace
ports:
- port: 9100 # Node Exporter端口
场景2:数据库隔离
需求:只允许API服务访问MySQL,禁止其他Pod连接。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: mysql-allow-api
spec:
podSelector:
matchLabels:
app: mysql
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: api-server
ports:
- port: 3306
场景3:出口流量管控
需求:禁止测试环境Pod访问外网,仅允许访问内部DNS。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: block-egress
spec:
podSelector:
matchLabels:
env: test
policyTypes:
- Egress
egress:
- to: # 允许访问Kubernetes DNS
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- port: 53
protocol: UDP
四、生产落地六大注意事项
-
CNI插件兼容性
- 支持NetworkPolicy的插件:Calico、Cilium、Weave Net等。
- 不支持:Flannel(需额外组件)、Docker自带的bridge网络。
验证命令:kubectl get networkpolicies.networking.k8s.io
(无报错则支持)。
-
渐进式实施策略
- 先监控:使用
audit
模式记录违规流量,不实际拦截。 - 再拦截:确认规则无误后切换到
enforce
模式。
工具推荐:Calico的NetworkPolicy Reporter
生成流量报告。
- 先监控:使用
-
命名空间级默认策略
建议每个Namespace创建默认拒绝规则:# default-deny.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny spec: podSelector: {} policyTypes: [Ingress, Egress]
-
与Service Mesh协同
- L4层控制:NetworkPolicy(IP/端口)。
- L7层控制:Istio/Linkerd(HTTP/gRPC方法、路径)。
典型架构:NetworkPolicy做粗粒度隔离,服务网格处理细粒度路由。
-
出口(Egress)策略陷阱
- DNS依赖:若未放行DNS查询,可能导致域名解析失败。
- 云元数据API:禁止Pod访问云厂商的元数据接口(防止SSRF攻击)。
-
性能影响评估
- Calico:万级策略规模下,iptables可能成为瓶颈。
- Cilium:基于eBPF,适合大规模策略(10万+规则)。
五、排错指南:策略不生效?快速诊断
步骤1:确认策略已应用
kubectl describe networkpolicy <policy-name>
# 检查Events是否报错(如标签不匹配)
步骤2:检查Pod标签
kubectl get pods --show-labels
# 确认目标Pod的标签与podSelector匹配
步骤3:模拟流量测试
使用临时Pod手动测试连通性:
# 测试从frontend到backend的80端口
kubectl run -it --rm test-$RANDOM --image=alpine --restart=Never \
--labels=app=frontend \
-- wget -qO- backend-service:80 --timeout=3
# 测试从其他Pod访问
kubectl run -it --rm test-$RANDOM --image=alpine --restart=Never \
-- wget -qO- backend-service:80 --timeout=3
步骤4:查看网络插件日志
# Calico日志
kubectl logs -n kube-system -l k8s-app=calico-node
# Cilium监控
kubectl exec -it cilium-xxxxx -- cilium monitor
六、总结:网络策略的进阶路线
- 基础隔离:按Namespace划分安全域,默认拒绝所有流量。
- 微服务矩阵:为每个服务定义精确的Ingress/Egress规则。
- 动态策略:结合Cilium的L7策略或Istio授权策略,实现基于身份的控制。
- 可视化:使用Hubble(Cilium)、Calico Enterprise等工具实时观察网络流量。
网络策略不是“一次性配置”,而需要随应用架构演进持续优化。记住:安全的本质是在便利性与风险之间找到平衡。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
· 【硬核科普】Trae如何「偷看」你的代码?零基础破解AI编程运行原理
· 单元测试从入门到精通
· 上周热点回顾(3.3-3.9)
· winform 绘制太阳,地球,月球 运作规律