如何在 K8s 內部實現(xiàn)安全的網絡隔離？

在生產環(huán)境中，隨著微服務架構和多租戶應用的普及，網絡安全和流量控制成為 Kubernetes 集群中不可忽視的關鍵問題。Kubernetes 默認允許集群內所有 Pod 間自由通信，但這在安全要求高的場景下顯然不夠。通過引入網絡策略（NetworkPolicy），我們可以對 Pod 之間甚至 Pod 與外部之間的網絡流量進行精細化控制，從而實現(xiàn)安全隔離和最小權限訪問。

本文將詳細介紹 Kubernetes 網絡策略的基本概念、工作原理、配置方法及實踐中的陷阱與最佳實踐，幫助你構建一個更加安全的集群網絡環(huán)境。

網絡策略簡介

什么是 NetworkPolicy？

• 定義：NetworkPolicy 是 Kubernetes 中的一種資源對象，用于定義 Pod 之間及與外部網絡之間允許或拒絕的流量規(guī)則。
• 目標：通過基于標簽的選擇器模型，實現(xiàn)應用為中心的網絡訪問控制和隔離，降低未經授權的流量風險。
• 作用域：網絡策略僅在所在的命名空間內生效，一旦某個 Pod 被 NetworkPolicy 選中，該 Pod 將默認處于隔離狀態(tài)，只允許明確允許的流量進入或離開。
• 核心原則：遵循白名單機制，策略未明確允許的流量均會被拒絕。

為什么需要網絡隔離？

• 安全性：限制未經授權的訪問，防止攻擊者在入侵集群后橫向滲透。
• 多租戶環(huán)境：在同一集群中，不同團隊或應用之間的隔離，有助于防止相互影響。
• 合規(guī)要求：滿足行業(yè)安全標準（如 PCI-DSS、HIPAA）對網絡分段的要求。
• 最小權限原則：只允許必要的網絡流量通過，從而降低風險面。

網絡策略的工作原理

基本模型

標簽選擇器（podSelector / namespaceSelector）：NetworkPolicy 使用標簽選擇器來確定哪些 Pod 受策略影響?？梢葬槍蝹€ Pod、一個 Pod 集合或整個命名空間設置規(guī)則。

規(guī)則類型：網絡策略分為兩種方向的規(guī)則：

• Ingress（入站規(guī)則）：控制哪些來源可以訪問目標 Pod。
• Egress（出站規(guī)則）：控制目標 Pod 可以訪問哪些外部資源。

端口與協(xié)議：支持指定 TCP、UDP 和 SCTP 協(xié)議的端口范圍（部分網絡插件可能限制協(xié)議支持）。

白名單機制

• 默認允許 VS 隔離：在未配置任何 NetworkPolicy 時，所有 Pod 間流量都是允許的。一旦 Pod 被任一 NetworkPolicy 選中，該 Pod 將進入隔離狀態(tài)，只有符合策略中白名單規(guī)則的流量才會被允許。
• 規(guī)則疊加：若多個策略作用于同一 Pod，所有規(guī)則的并集生效（即流量只需匹配任一策略即可通過）。
• 雙向校驗：流量需同時滿足源和目標的策略規(guī)則。例如，Pod A 允許出口到 Pod B，但 Pod B 未允許來自 Pod A 的入口，則連接仍會被拒絕。

網絡插件支持

實現(xiàn)依賴：網絡策略的實際執(zhí)行依賴于 CNI 插件（如 Calico、Cilium、Weave Net、kube-router 等）。不同插件可能在細節(jié)上有差異，但基本原理一致。

插件選型指南：

• Calico：支持復雜策略（如基于域名的出口規(guī)則）、高性能，適合大規(guī)模集群。
• Cilium：支持 L7 策略、服務網格集成，適合需要深度流量分析的場景。
• Weave Net：配置簡單，適合中小規(guī)模集群。

驗證插件支持：通過部署測試策略并觀察流量行為，或查閱插件官方文檔確認功能支持。

常見配置示例

基礎示例

以下策略對 default 命名空間中帶有 role=db 標簽的 Pod 進行隔離，規(guī)定僅允許來自以下來源的 TCP 流量訪問 6379 端口：

• 來自 IP 地址塊 172.17.0.0/16，但排除 172.17.1.0/24。
• 來自帶有標簽 project=myproject 的命名空間中的 Pod。
• 來自當前命名空間中帶有標簽 role=frontend 的 Pod。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:  # 注意：此規(guī)則隱含了同一命名空間下的 Pod
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

默認拒絕策略

設置命名空間內所有 Pod 默認拒絕所有入站流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: default
spec:
  podSelector: {}  # 選中所有 Pod
  policyTypes:
  - Ingress
  # ingress 規(guī)則為空，表示拒絕所有入站

允許特定訪問

僅允許帶有 access: true 標簽的 Pod 訪問 nginx：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"

關鍵場景擴展

允許 DNS 解析

Pod 通常需要訪問集群 DNS（如 kube-dns）以解析服務名稱。若出口策略限制嚴格，需顯式放行 DNS 流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
spec:
  podSelector: {}
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system  # 假設 DNS 部署在 kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
      - protocol: UDP
        port: 53

允許訪問外部服務

若 Pod 需訪問特定外部 API（如 api.example.com:443），可通過 IP 塊或域名（需插件支持）放行：

egress:
- to:
  - ipBlock:
      cidr: 203.0.113.0/24  # 替換為實際 IP 范圍
  ports:
  - protocol: TCP
    port: 443

實踐部署與注意事項

部署步驟

選擇并配置網絡插件

• 確認插件支持 NetworkPolicy（如 Calico：kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml）。
• 驗證插件功能：部署測試策略并觀察流量是否被正確攔截。

設計標簽體系

• 為 Pod 和命名空間定義清晰的標簽（如 app: frontend, tier: database）。
• 使用 kubectl label 命令動態(tài)管理標簽。

漸進式策略部署

• 先隔離：應用默認拒絕策略（Deny All）。
• 后放通：按需添加允許規(guī)則，逐步開放必要流量。
• 監(jiān)控審計：結合日志工具（如 Cilium Hubble）觀察策略匹配情況。

跨命名空間策略

使用 namespaceSelector 控制跨命名空間訪問。

示例：允許 monitoring 命名空間下的 Prometheus Pod 拉取指標：

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: monitoring
    podSelector:
      matchLabels:
        app: prometheus

常見問題與排查

策略未生效的可能原因

1. 網絡插件未正確支持：執(zhí)行 kubectl get networkpolicy 確認策略已創(chuàng)建，但插件可能未生效。
2. 標簽不匹配：檢查 Pod 和命名空間的標簽是否與策略中的選擇器一致。
3. 端口/協(xié)議不匹配：確保流量協(xié)議（TCP/UDP）和端口號與策略定義一致。
4. 規(guī)則方向錯誤：入站流量需配置在 ingress，出站流量需 egress。

測試工具

臨時診斷 Pod：使用 nicolaka/netshoot 或 busybox 鏡像執(zhí)行 curl 或 nslookup。

kubectl run tester --image=nicolaka/netshoot --rm -it --restart=Never -- curl http://nginx:80

策略模擬工具：Calico 提供 calicoctl 模擬策略效果。

高級技巧與最佳實踐

復雜規(guī)則組合

聯(lián)合選擇器：namespaceSelector 和 podSelector 在同一個 from/to 塊中時，需同時滿足（“與”關系）：

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        env: prod
    podSelector:
      matchLabels:
        app: api

此規(guī)則僅允許來自 env=prod 命名空間且標簽為 app=api 的 Pod。

性能優(yōu)化

• 避免寬泛規(guī)則：如 podSelector: {} 可能影響性能，盡量縮小選擇器范圍。
• 合并相似規(guī)則：減少策略數(shù)量以降低插件處理開銷。

安全增強

默認拒絕出口：防止數(shù)據泄露，僅允許訪問必要的外部服務。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

定期審計策略：使用 kubectl get networkpolicy --all-namespaces 檢查冗余或過期規(guī)則。

總結

通過 Kubernetes 網絡策略，可以實現(xiàn)從粗放式網絡開放到精細化管控的轉變。核心要點包括：

• 零信任模型：默認拒絕所有流量，按需放行。
• 多維控制：基于標簽、命名空間、IP/CIDR 等多維度定義規(guī)則。
• 生態(tài)協(xié)同：結合服務網格（如 Istio）實現(xiàn) L7 控制，或使用 Cilium 增強可觀測性。

隨著集群規(guī)模擴大，建議采用策略即代碼（Policy as Code）工具（如 OPA Gatekeeper）自動化策略管理，確保安全性與合規(guī)性的同時降低運維負擔。網絡策略不僅是技術手段，更是構建云原生安全體系的核心基石。

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論