随笔 - 367  文章 - 0  评论 - 5  阅读 - 5730

k8s的网络策略

Kubernetes网络策略实战指南:如何锁紧集群的网络流量


一、为什么需要网络策略?生产环境中的真实痛点

Kubernetes默认允许所有Pod自由通信,这给生产环境埋下重大安全隐患。以下是两个真实场景:

  1. 敏感数据泄露:日志收集Pod意外连接到未授权的数据库Pod,导致数据泄露。
  2. 横向攻击扩散:黑客入侵前端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)。
  • 逻辑组合fromto中的多个条件是“或”关系,同一块内的条件是“与”关系。

三、生产环境经典场景与配置示例

场景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

四、生产落地六大注意事项

  1. CNI插件兼容性

    • 支持NetworkPolicy的插件:Calico、Cilium、Weave Net等。
    • 不支持:Flannel(需额外组件)、Docker自带的bridge网络。
      验证命令kubectl get networkpolicies.networking.k8s.io(无报错则支持)。
  2. 渐进式实施策略

    • 先监控:使用audit模式记录违规流量,不实际拦截。
    • 再拦截:确认规则无误后切换到enforce模式。
      工具推荐:Calico的NetworkPolicy Reporter生成流量报告。
  3. 命名空间级默认策略
    建议每个Namespace创建默认拒绝规则:

    # default-deny.yaml
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: default-deny
    spec:
      podSelector: {}
      policyTypes: [Ingress, Egress]
    
  4. 与Service Mesh协同

    • L4层控制:NetworkPolicy(IP/端口)。
    • L7层控制:Istio/Linkerd(HTTP/gRPC方法、路径)。
      典型架构:NetworkPolicy做粗粒度隔离,服务网格处理细粒度路由。
  5. 出口(Egress)策略陷阱

    • DNS依赖:若未放行DNS查询,可能导致域名解析失败。
    • 云元数据API:禁止Pod访问云厂商的元数据接口(防止SSRF攻击)。
  6. 性能影响评估

    • 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

六、总结:网络策略的进阶路线

  1. 基础隔离:按Namespace划分安全域,默认拒绝所有流量。
  2. 微服务矩阵:为每个服务定义精确的Ingress/Egress规则。
  3. 动态策略:结合Cilium的L7策略或Istio授权策略,实现基于身份的控制。
  4. 可视化:使用Hubble(Cilium)、Calico Enterprise等工具实时观察网络流量。

网络策略不是“一次性配置”,而需要随应用架构演进持续优化。记住:安全的本质是在便利性与风险之间找到平衡。

posted on   Leo-Yide  阅读(7)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
· 【硬核科普】Trae如何「偷看」你的代码?零基础破解AI编程运行原理
· 单元测试从入门到精通
· 上周热点回顾(3.3-3.9)
· winform 绘制太阳,地球,月球 运作规律
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

点击右上角即可分享
微信分享提示