Linux中國

Kubernetes 網路策略基礎

隨著越來越多的雲原生應用程序通過 Kubernetes 部署到生產環境,安全性是你必須在早期就需要考慮的一個重要檢查項。在設計雲原生應用程序時,預先嵌入安全策略非常重要。不這樣做會導致後續的安全問題,從而導致項目延遲,並最終給你帶來不必要的壓力和金錢投入。

這麼多年來,人們總是把安全留到最後,直到他們的部署即將發布到生產環境時才考慮安全。這種做法會導致項目交付的延遲,因為每個組織都有要遵守的安全標準,這些規定被繞過或不遵守,並承受大量的風險才得以實現可交付成果。

對於剛開始學習 Kubernetes 實施的人來說,理解 Kubernetes 網路策略 NetworkPolicy 可能會令人生畏。但這是在將應用程序部署到 Kubernetes 集群之前必須了解的基本要求之一。在學習 Kubernetes 和雲原生應用程序時,請把「不要把安全拋在腦後!」定為你的口號。

NetworkPolicy 概念

網路策略 NetworkPolicy 取代了你所知道的數據中心環境中的防火牆設備 —— 如 吊艙 Pod 之於計算實例、網路插件之於路由器和交換機,以及卷之於存儲區域網路(SAN)。

默認情況下,Kubernetes 網路策略允許 吊艙 Pod 從任何地方接收流量。如果你不擔心吊艙的安全性,那麼這可能沒問題。但是,如果你正在運行關鍵工作負載,則需要保護吊艙。控制集群內的流量(包括入口和出口流量),可以通過網路策略來實現。

要啟用網路策略,你需要一個支持網路策略的網路插件。否則,你應用的任何規則都將變得毫無用處。

Kubernetes.io 上列出了不同的網路插件:

  • CNI 插件:遵循 容器網路介面 Container Network Interface (CNI)規範,旨在實現互操作性。
    • Kubernetes 遵循 CNI 規範的 v0.4.0 版本。
  • Kubernetes 插件:使用橋接器和主機本地 CNI 插件實現基本的 cbr0

應用網路策略

要應用網路策略,你需要一個工作中的 Kubernetes 集群,並有支持網路策略的網路插件。

但首先,你需要了解如何在 Kubernetes 的環境使用網路策略。Kubernetes 網路策略允許 吊艙 從任何地方接收流量。這並不是理想情況。為了吊艙安全,你必須了解吊艙是可以在 Kubernetes 架構內進行通信的端點。

1、使用 podSelector 進行吊艙間的通信:

 - namespaceSelector:
    matchLabels:
      project: myproject 

2、使用 namespaceSelector 和/或 podSelectornamespaceSelector 的組合進行命名空間之間的通信和命名空間到吊艙的通信。:

 - namespaceSelector:
    matchLabels:
      project: myproject
 - podSelector:
    matchLabels:
      role: frontend 

3、對於吊艙的 IP 塊通信,使用 ipBlock 定義哪些 IP CIDR 塊決定源和目的。

 - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24 

注意吊艙、命名空間和基於 IP 的策略之間的區別。對於基於吊艙和命名空間的網路策略,使用選擇器來控制流量,而對基於 IP 的網路策略,使用 IP 塊(CIDR 範圍)來定義控制。

把它們放在一起,一個網路策略應如下所示:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 192.168.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

參考上面的網路策略,請注意 spec 部分。在此部分下,帶有標籤 app=backendpodSelector 是我們的網路策略的目標。簡而言之,網路策略保護給定命名空間內稱為 backend 的應用程序。

此部分也有 policyTypes 定義。此欄位指示給定策略是否適用於選定吊艙的入口流量、選定吊艙的出口流量,或兩者皆有。

spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress

現在,請看 Ingress(入口)和 Egress(出口)部分。該定義規定了網路策略的控制。

首先,檢查 ingress from 部分。

此實例中,網路策略允許從以下位置進行吊艙連接:

  • ipBlock
    • 允許 172.17.0.0/16
    • 拒絕 192.168.1.0/24
  • namespaceSelector
    • myproject: 允許來自此命名空間並具有相同標籤 project=myproject 的所有吊艙。
  • podSelector
    • frontend: 允許與標籤 role=frontend 匹配的吊艙。
ingress:
 - from:
  - ipBlock:
      cidr: 172.17.0.0/16
      except:
      - 192.168.1.0/24
  - namespaceSelector:
      matchLabels:
        project: myproject
  - podSelector:
      matchLabels:
        role: frontend

現在,檢查 egress to 部分。這決定了從吊艙出去的連接:

  • ipBlock
    • 10.0.0.0/24: 允許連接到此 CIDR
    • Ports: 允許使用 TCP 和埠 5978 進行連接
egress:
 - to:
  - ipBlock:
      cidr: 10.0.0.0/24
  ports:
  - protocol: TCP
    port: 5978

網路策略的限制

僅靠網路策略無法完全保護你的 Kubernetes 集群。你可以使用操作系統組件或 7 層網路技術來克服已知限制。你需要記住,網路策略只能解決 IP 地址和埠級別的安全問題 —— 即開放系統互聯(OSI)中的第 3 層或第 4 層。

為了解決網路策略無法處理的安全要求,你需要使用其它安全解決方案。以下是你需要知道的一些 用例,在這些用例中,網路策略需要其他技術的增強。

總結

了解 Kubernetes 的網路策略很重要,因為它是實現(但不是替代)你通常在數據中心設置中使用的防火牆角色的一種方式,但適用於 Kubernetes。將此視為容器安全的第一層,僅僅依靠網路策略並不是一個完整的安全解決方案。

網路策略使用選擇器和標籤在吊艙和命名空間上實現安全性。此外,網路策略還可以通過 IP 範圍實施安全性。

充分理解網路策略是在 Kubernetes 環境中安全採用容器化的一項重要技能。

via: https://opensource.com/article/21/10/kubernetes-networkpolicy

作者:Mike Calizo 選題:lujun9972 譯者:perfiffer 校對:wxy

本文由 LCTT 原創編譯,Linux中國 榮譽推出


本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive

對這篇文章感覺如何?

太棒了
0
不錯
0
愛死了
0
不太好
0
感覺很糟
0
雨落清風。心向陽

    You may also like

    Leave a reply

    您的電子郵箱地址不會被公開。 必填項已用 * 標註

    此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據

    More in:Linux中國